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ABSTRACT 


This  documentation  provides  a  complete  description 
of  the  Division  War  Game  (DIVWAG)  Model  as  it  exists 
on  1  April  1976.  The  documentation  is  composed  of  an 
Executive  Summary  (Volume  I) ,  an  Analyst/Programmer 
Manual  (Volume  II) ,  and  the  Planner/User  Manual  (Volume 
III) .  Described  within  the  volumes  are  the  model 
design  and  development;  application;  capabilities; 
limitations;  facility,  equipment,  and  personnel 
requirements;  data  input  requirements;  mathematical 
and  logical  processes;  program  descriptions*  output 
descriptions;  user  instructions;  and  diagnostic 
messages.  This  documentation  was  originally  produced 
in  April  1973  by  Computer  Sciences  Corporation  (CSC) 
under  Contract  DAAG  11-70-0875. 
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CHAPTER  1 


INTRODUCTION 


1.  PURPOSE.  The  purpose  of  this  volume  is  to  provide  prospective  users  of 
the  Division  War  Game  (DIVWAG)  Model  with  the  background,  description,  pro¬ 
cedures,  and  techniques  necessary  for  understanding  and  operating  the  model 
in  a  division  force  evaluation. 

2.  SCOPE.  This  volume  provides  the  procedures,  rules,  and  techniques  for 
the  operational  use  of  the  DIVWAG  Model  in  the  conduct  of  an  analytical  task. 
This  chapter  provides  background  information  relative  to  war  gaming  and  a 
nontechnical  description  of  the  DIVWAG  system  necessary  for  understanding 
the  computer  assistance  provided  in  the  war  game.  Chapter  2  describes  game 
operations,  exclusive  of  the  dynamic  game  play.  Chapter  3  details  the  DIVWAG 
game  period  operational  sequence  and  describes  the  dynamic  play  operations 
for  applying  DIVWAG. 

3.  BACKGROUND: 

a.  Description  of  a  Game: 

(1)  A  game  is  a  form  of  human  endeavor,  sometimes  recreational, 
distinguished  from  other  forms  of  activity  by  having  rules  and  a  payoff.  In 
return  for  adhering  to  the  rules,  the  player  receives  a  reward.  The  rules 
are  arbitrary,  and  many  payoff  schemes  exist.  Payoff  can  be  determined  by 
chance,  as  in  dice  or  roulette;  a  function  of  skill,  as  in  stud  poker,  busi¬ 
ness,  or  football;  or,  in  the  British  sense,  obtained  from  playing  the  game 
with  class  (win  or  lose),  as  in  war.  Some  games  are  personally  competitive, 
one  player's  gain  being  another  player's  loss.  Competition  adds  to  player 
interest;  however,  the  most  interesting  games,  with  all  due  respect  to  the 
adherents  of  craps,  roulette,  and  basketball,  are  the  intellectual  ones. 

(2)  Intellectual  games  have  extensions  in  time,  both  past  and 
future.  Each  action  by  a  player  produces  a  new  state  (situation),  and  each 
action  is  a  function  of  the  existing  state;  therefore,  each  action  by  a 
player  is  dependent  on  all  the  past  actions  taken  by  players.  In  addition, 
a  player  is  required  to  project  into  the  future  the  events  that  his  action 
will  unleash.  Reward  accrues  to  the  player  who  can  most  successfully  accomp¬ 
lish  the  projection.  The  game  becomes  an  intricate,  changing  tapestry,  which 
takes  on  the  form  of  all  the  past  decisions  of  the  players.  Chess,  war, 
politics,  and  billiards  are  examples  of  games  with  extensions  in  time. 
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b.  Characteristics  of  a  War  Game: 


(1)  A  war  game  is  a  game  having  as  its  goal  the  replication  of  one 
or  more  of  the  manifestations  of  war;  that  is,  the  states  through  which  the 
game  passes  should  be  similar,  to  some  degree  of  detail,  to  situations 
encountered  in  war.  The  generation  of  this  similarity  is  accomplished  by 
requiring  that  the  game  rules  and  payoff  calculations  interact  in  a  way  that 
transitions  a  starting  state,  assumed  to  be  realistic,  to  successive  realistic 
states.  Each  action  by  a  game  player,  done  in  accordance  with  the  game  rules, 
results  in  a  payoff  calculation,  which  in  turn  produces  a  new  game  state.  The 
cycle  then  repeats  (Figure  1-1) . 

(2)  Identification  of  the  rules  constitutes  a  problem  in  war  gaming. 
If  the  rules  were  immutable,  they  could  be  written  down  and  machines  taught 
to  play  a  passable  game.*  This  technique  is,  in  fact,  used  for  tiny  wars; 
and  simulations,  untouched  by  human  hands,  come  into  their  own.  For  grand 
wars,  however,  some  of  the  rules  for  the  replicating  game  are  expressed  as 
constraints  on  player  actions.  This  expression  of  constraints  takes  the 
form  of  player  conformity  to  what  he  and  the  other  players  regard  as  gener¬ 
ally  accepted  normal  behavior.  Normal  behavior  may  admit  very  few  choices 
for  a  player  decision,  or  alternatively,  a  continuous  band  of  choices. 

(3)  The  other  rules,  those  which  do  not  constrain  player  action, 
concern  translating  the  existing  situation  plus  the  player  decision  into  the 
next  situation.  It  is  important  for  the  player  to  understand  these  rules; 
otherwise,  he  will  have  no  appreciation  of  the  consequences  of  his  actions, 
and  the  final  game  situation  will  be  nothing  more  than  a  random  event.  It  is 
axiomatic  among  those  who  devise  the  rules  for  translating  the  game  situation 
plus  decisions  into  the  next  situation  (i.e. ,  model  builders)  that  players 
should  not  know  how  this  is  done.  It  needs  to  be  understood  that  the  require¬ 
ment  for  such  an  axiom  implies  subterfuge  on  the  part  of  model  builders. 

(4)  Although  machines  can  be  taught  to  play  games,  it  is  generally 
accepted  that  use  of  the  word  "game"  implies  human  participation.  Since  some 
games  are  used,  not  for  entertainment,  but  for  the  study  of  war,  an  under¬ 
standing  of  the  merits  of  simulations  (machine  games)  and  war  games  (human 
gamers)  becomes  necessary.  There  are  four  valid  reasons  for  using  a  human 
player  in  the  replication  of  war: 

.  The  player  is  to  be  trained. 

.  A  human  player  is  innovative. 


1.  Even  if  the  rules  can  be  written  down,  there  is  no  guarantee  that  a 
machine  can  be  taught  to  play  a  good  game.  A  prime  example  is  chess.  The 
heuristics  of  searching  the  future  for  a  good  move  are  inadequately  understood 
even  for  this  ancient  and  well-studied  game. 
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WAR  SAME  CYCLE 


S,  •  INITIAL  SAME  STATE 
3„«  FINAL  GAME  STATE 

T|  •  PAYOFF  -  RESULTING  FROM  EACH  FLAYER  MOVE 

R  •  TOTAL  OAME  PAYOFF 

Sj*  SU|»<i  +  |),h  OAME  STATE 

d;  ■  PLAYER  DECISION/ACTION/MOVE  MADE  IN 
1  ACCORDANCE  WITH  THE  RULES 

note:  all  of  these  variables  are  multicomponent  vectors;  d|  is  a 

SET  OF  DECISIONS,  NOT  A  SINGLE  DECISION, 
j  •  GAME  STATE  INDEX 
n  •  FINAL  OAME  STATE  INDEX 


Figure  1-1.  War  Game  Cycle 


.  The  player  rules  cannot  be  formalized  to  a  degree  adequate  for 
programming  a  machine. 

.  The  player  rules  are  so  involved  that  machine  programming  becomes 
inefficient  and  wasteful. 

The  training  of  a  player  is  a  valid  reason  only  for  that  class  of  games 
designed  especially  for  training  purposes.  The  second  reason,  the  require¬ 
ment  for  innovation,  has  come  to  be  discouraged,  the  result  of  a  level  of 
sophistication  requiring  that  a  series  of  games  be  absolutely  comparable  one 
with  another  rather  than  a  sequence  in  an  optimization  scheme.  Thus,  the 
remaining  two  reasons  for  using  human  players  in  war  gaming  are  operative; 
the  human  player  is  used  from  necessity  rather  than  choice.  The  return  for 
simplifying  the  model  builder's  task  apparently  overshadows  the  difficulties 
generated  for  the  person  responsible  for  making  comparisons  among  games. 

(5)  In  practice  the  necessity  for  using  a  human  does  not  exclude  the 
machine  player.  The  process  of  transitioning  a  game  from  one  state  to  the 
next  is  gradually  being  taken  over  by  computers,  and  it  is  natural  to  let  the 
machine  play  small  games  and  eliminate  some  of  the  arbitrary  rules. ^  The 
result  of  this  trend  is  affecting  the  design  of  war  games.  More  and  more  the 
design  of  a  game  is  becoming  a  matter  of  selecting  the  man-machine  interface 
echelon.  Above  some  echelon,  the  man  makes  the  decisions;  below,  the  machine 
makes  the  decisions. 

(6)  Despite  the  ambiguities  introduced  by  a  human  player,  a  war  game 
is  a  valuable  analytical  procedure.  Problems  that  can  be  treated  in  no  other 
way  can  be  studied  in  a  war  game.  This  class  includes  large  problems,  complex 
problems,  and  problems  that  are  not  well  understood.  The  production  of  a 
sequence  of  game  states  amounts  to  the  fragmenting  of  a  large  problem  into  a 
set  of  smaller  interconnected  problems,  and  the  decisions  required  at  each 
game  state  focus  the  attention  of  the  player  on  the  important  elements  of  the 
problem.  An  effective  war  game  produces  a  number  of  subproblems,  which  may 

be  much  more  amenable  to  analysis. 

(7)  A  significant  characteristic  of  a  war  game  is  that  its  successful 
conduct  requires  a  tremendous  amount  of  communication.  Often  this  communica¬ 
tion  must  take  place  among  players  with  diverse  skills  and  backgrounds.  The 
analyst  must  explain  to  the  player  why  he  must  know  certain  things,  the  player 
must  explain  military  tactics  to  the  rule  keeper  (model  builder) ,  and  the 
whole  game  must  be  explained  to  sponsors  who  were  not  players. 


2.  The  elimination  of  arbitrary  rules  is  good;  however,  in  many  cases 
the  rules  are  based  on  experience.  Replacement  of  the  experience  base  with 
a  poorly  taught  machine  is  not  good. 
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(8)  War  games  also  have  disadvantages,  including: 

.  Results  are  replicable  only  with  great  difficulty. 

.  Value  of  a  game  is  a  direct  function  of  the  skill  of  the  game 
team.  An  effective  team  is  difficult  to  build,  and  there 
are  no  mediocre  ones.  They  are  either  good  or  very  bad. 

.  Results  are  more  subject  to  controversy  than  those  generated  by 
machines.  (A  computer's  subjective  judgments  are  more  easily 
concealed. ) 

.  A  game  is  more  subject  to  external  pressure.  (Computer  decisions 
can  be  manipulated  also,  but  only  overtly  and  with  difficulty.) 

c.  Classification  of  War  Games.  War  games  are  classified  by  describing 
the  purpose,  the  form,  and  the  information  constraint. 

(1)  The  purpose  of  a  game  may  be  to  train  players,  to  test  operational 
plans,  or  to  research  the  composition  and  conduct  of  forces  used  in  war.^ 

(2)  The  form  of  a  game  may  be  either  free  or  rigid.  These  terms  are 
historical  and  refer  to  the  relative  dependence  of  the  game  on  formalized 
rules.  A  rigid  game  depends  entirely  on  rules.  Transition  of  the  game  from 
one  state  to  the  other  is  determined  from  tables  and  calculations.  The 
results  of  player  decisions  are  determined  by  reference  to  rules.  Opposed 

to  the  rigid  game  is  the  free  game.  In  the  free  game  a  controller  decides 
i*  :es  solely  on  the  basis  of  his  judgment.  A  free  game  is  very  fast,  more 
fun,  and  possibly,  nearly  as  effective  as  a  rigid  game.4  Most  war  games  are 
a  mixture  of  free  and  rigid,  with  a  recent  steep  trend  toward  the  use  of 
rigid  games  in  research. 

(3)  Classification  of  a  game  according  to  information  constraint 
determines  what  the  players  are  allowed  to  know  about  each  other.  In  a  com¬ 
pletely  open  game  total  information  is  provided  each  player.  In  a  closed 
game  only  certain  elements  of  the  game  state  of  the  opposing  player  are 
known.  Game  rules  decide  what  information  to  provide.  It  can  become  a  game 
refinement  to  let  these  rules  correspond  to  the  information-collecting 


3.  A  more  basic  purpose  for  a  war  game  was  expressed  by  an  unnamed  WWII 
General  of  the  Greater  German  Empire  who  stated,  "The  purpose  of  the  exercise 
was  to  provide  the  opportunity  for  raising  and  discussing  controversial  pro¬ 
blems  with  a  selected  and  critical  circle."  (War  Games.  Office  of  Military 
History,  Department  of  the  Army,  Washington,  D.C.,  1952.) 

4.  J.P.  Young,  A  Survey  of  Historical  Developments  in  War  Games, 
ORO-SP-98,  Operations  Research  Office,  Bethesda,  Maryland,  1959. 
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capability  of  the  player.  An  open  game  is  advantageous  when  speed  of  play  or 
increased  management  control  is  required.  Although  information  constraint 
and  speed  of  play  or  management  control  do  not  appear  to  be  correlated,  they 
are  in  fact  related  inexorably  for  most  modern  war  games.  Intelligence  play 
has  become  an  absolute  requirement  for  a  war  game.  Even  if  a  player  has 
100  percent  knowledge  of  his  opponent,  an  open  game,  he  can  act  only  on  the  ( 

knowledge  that  he  might  reasonably  be  expected  to  gain  in  real  life.  As  a 
result,  there  is  no  apparent  difference  between  the  events  of  an  open  game 
and  the  events  of  a  closed  game.  As  a  practical  matter  the  difference  occurs 
in  the  way  the  gaming  staff  is  organized. 

* 

(a)  In  organizing  for  an  open  game,  the  staff  controlling  the 
game  and  the  playeT  staffs  are  formed  into  a  single  committee  chaired  by  the 
game  director.  The  players  become  functional  specialists  whose  purpose  is  to 
offer  advice.  The  game  decision  base  becomes  flexible  and,  in  the  extreme, 
may  consist  only  of  the  game  director.  The  result  of  this  organization  and 
the  resultant  narrowed  decision  base  is  a  reduction  in  the  requirement  for 
multipoint  communication,  always  a  time  consumer,  and  a  reduction  in  the 
occurrence  of  the  unexpected.  The  game  operates  under  the  guidance  of  a 
single  intellect.  Player  sparring  and  unnecessary  activities  are  eliminated, 
and  the  operation  is  very  efficient.  An  open  game,  however,  has  all  the 
characteristics  of  playing  Monopoly  with  oneself.  It  is  very  hard  to  be 
creative  and  very  easy  to  be  bored  and  mediocre.  Much  can  be  learned  of 
rules,  but  very  seldom  can  the  intellect  be  really  challenged.  An  open  game 
is  an  effective  user  of  time  and  things,  and  a  very  inadequate  user  of  human 
resources. 

(b)  The  closed  game  is  an  almost  exact  contrapositive  of  the 
open  game.  What  the  closed  game  does  well,  the  open  game  does  not,  and  vice 
versa.  A  staff  that  does  well  on  open  games  will  not  do  well  on  closed  games. 

The  converse  is  also  true.  A  closed  game  is  more  realistic  for  the  players. 

They  also  have  their  own  professionalism  at  stake.  A  closed  game  is  generally 
accompanied  by  much  fire,  smoke,  and  friction,  the  result  of  breakdowns  in 
communication.  The  controlling  staff  has  its  work  cut  out  for  it,  and  the 

game  management  needs  patience.  The  payoff  for  this  kind  of  effort  is  many  ^ 
interesting  problems  and  a  great  deal  of  insight.  Closed  games,  therefore, 
are  ideal  for  optimization  schema. 

d.  Computer-assisted  War  Gaming: 

(1)  There  are  two  types  of  computer-assisted  war  games,  which  may  • 

be  referred  to  as  Type  A  and  Type  B. 

(a)  In  the  Type  A  game  the  computer  functions  only  as  a  very 
efficient  bookkeeper.  Its  functions  are  limited  to  elementary  computations 
and  the  formatting  of  feedback  data.  Decision  logic  is  not  employed;  thus,  ' 

the  personnel  employed  in  the  game  retain  their  decision-making  responsibilities. 
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(b)  In  a  Type  B  war  game  che  computer  takes  on  all  or  some  of 
the  responsibility  for  controlling  the  action  of  the  game  and  plays  some 
parts  of  the  game.  Extensive  decision  logic  is  used.  Development  of  Type  B 
games  has  the  goal  of  restricting  human  participation  to  either  key  issues 
(those  requiring  innovation)  or  decisions  absolutely  requiring  human  input 
(those  for  which  logic  is  not  programmable). 

(2)  A  pure  Type  A  or  Type  B  war  game  does  not  exist.  Existent  games 
are  a  mixture;  however,  at  the  present  time  most  games  are  predominantly 
Type  A.  The  rules  and  calculations  of  what  is  philosophically  a  hand-operated 
game  are  programmed,  and  an  interface  between  players  and  machine  is  defined. 
In  most  cases  rules  are  extended  and  more  detail  considered  because  of  the 
increased  manipulative  capability  of  the  computer.  This  extension  of  the 
rules  may  take  the  form  of  incorporating  a  simulation  into  the  game.  In  this 
case  the  simulation  is  merely  an  elegant  formulation  of  a  rule.  The  game  may 
still  be  of  Type  A,  because  a  simulation  may  or  may  not  describe  faithfully 
a  situation  requiring  a  representation  of  human  decision  making. 

(a)  Decision  making  in  a  simulation  accomplished  by  using  an 
average  decision,  a  most  probable  decision,  or  the  selection  of  a  decision  in 
a  random  fashion  from  a  stated  distribution  is  a  disservice  to  the  real  thing. 
When  a  chain  of  such  decisions  is  linked  together,  reality  may  become  the 
victim. 


(b)  When  a  decision  is  represented  by  a  rule/ simulation  it  is 
assumed  that  the  stated  result  always  occurs.  For  many  situations  this  is 
true;  e.g.,  the  squad  leader  may  not  have  many  choices;  however,  a  brigade 
commander  has  many  options.  A  simulation  of  brigade  activities,  used  so  that 
a  human  player  is  required  to  consider  only  those  decisions  required  at  the 
division  echelon,  must  consider  decisions  logically. 

e.  Use  of  War  Games: 

(1)  War  games  are  the  primary  analytical  tools  to  assist  in  the 
orderly  examination  of  conflict  situations  involving  military  units  and 
systems.  The  entire  framework  of  a  war  game  is  open  for  inspection  by  a 
force  planner  so  that  the  applicability  of  game  results  to  hardware  procure¬ 
ment  and  organizational  development  can  be  Btudied  in  detail. 

(2)  War  games  can  support  research  in  a  variety  of  ways.  They  can, 
even  in  their  formative  stages,  provide  considerable  broad  general  insight 
into  critical  problems  in  study  areas;  they  can  generate  distributions  of 
outcomes  of  play  of  specific  situations;  and  they  can  function  as  pseudo¬ 
experiments,  producing  data  for  analysis  after  the  plays  are  completed. 


5.  Such  functions  are  termed  pathologically  bimodal.  In  translation 
this  term  means  that  the  simulation  is  schizophrenic.  The  result  has  an 
ill-defined  relationship  to  the  input. 
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(3)  The  analytic  use  of  a  war  game  is  possible  only  when  efforts 
have  been  made  to  ensure  that  the  required  elements  of  game  record,  or  data, 
are  available.  Given  a  basic  operational  structure  of  movement,  contact,  and 
battle  between  the  opposing  resolved  units,  the  approach  is  one  of  introduc¬ 
ing  detailed  simulations  of  the  real  world  events  to  be  studied.  These 
simulations  result  from  cooperative  effort  between  the  game  staff  and  the 
analysts  of  the  proponent  agency.  Research  objectives  are  used  to  develop  l 

the  simulation  models,  rules  of  play,  and  assessment  procedures  that  ensure 
events  pertinent  to  the  problems  do  occur  in  the  course  of  play  and  that  the 
desired  data  for  analysis  are  taken.  One  criticism  that  has  been  leveled 
against  the  conduct  of  war  games  is  that  the  analysts  have  conspicuously 
failed  to  reap  the  rewards  in  doing  analytic  research  based  on  data  from 
their  games.  A  point  easily  lost  is  that  the  play  of  the  war  game  merely 
produces  data  for  detailed  analysis.  The  data  produced  from  the  play  of  the 
war  game  must  be  interpreted  and  evaluated  to  produce  insights,  findings,  and 
conclusions  that  are  valid  for  the  situation  being  simulated  in  the  game; 
reliable  in  the  sense  that  repeated  play  of  the  same  plans  and  set  of  condi¬ 
tions  would  yield  similar  results  within  the  limits  of  chance  variation;  and 
useful  for  predicting  results  for  related  situations.  The  actual  results 
of  the  game  must  be  analyzed,  and  the  analysis  must  also  appraise  the  validity 
of  the  input  data,  the  rules  and  assumptions  made,  the  availability  of  resources 
consumed,  and  the  strategy  and  tactics  utilized  by  the  player  teams.  Such 
analysis  can  be  a  great  source  of  information  to  the  sponsor  of  the  study 
effort  and  can  help  justify  the  expense  of  the  game.  Applying  a  structural 
methodology  to  the  output  of  the  war  game  takes  it  out  of  the  realm  of 
philosophy  and  back  into  the  science  of  operations  research. 

4.  SYSTEM  DESCRIPTION.  The  DIVWAG  system  is  described  in  this  paragraph  in 
terms  of  its  objective,  its  capabilities,  and  its  components. 

a.  System  Objective.  The  DIVWAG  Model  was  developed  as  a  computer-assisted 
war  gaming  system  for  use  in  simulating  military  interactions  between  opposing 
division-size  forces  and  their  major  elements,  with  outputs  permitting  evalua¬ 
tion  and  comparison  of  the  combat  effectiveness  of  such  division  forces.  The 
DIVWAG  Model  objective  is  to  provide  means  for  determining  the  impact  on 
force  effectiveness  of  changes  in  the  mixes  of  major  weapons  and  other  systems  y 
The  DIVWAG  Model  permits  two-sided  simulations.  The  games  using  the  DIVWAG  ** 
Model  can  be  open,  semi-open,  or  closed.  The  games  will  be  basically  rigid, 
but  the  model  can  be  operated  with  semi-rigid  intelligence  and  special  weapons 
assessment.  Resolution  is  partially  adjustable.  Time  resolution  may  be  as 
small  as  a  hundredth  of  a  minute  (0.01  minute),  space  resolution  as  small  as 
one  meter,  and  unit  resolution  as  small  as  one  individual;  however,  for  * 

practical  gaming  purposes,  unit  resolution  is  on  the  order  of  a  battalion, 
depending  on  terrain  scale  and  size  forces  being  gamed. 


b.  Model  Capabilities.  The  model  capabilities  are  discussed  in  terms  of 
operational  capabilities  and  operational  scope. 
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(1)  Operational  Capabilities.  The  DIVWAG  Model  has  the  following 
operational  capabilities: 

(a)  Producing  data  for  use  in  evaluating  effectiveness  of  forces 
composed  of  maneuver  units  and  their  associated  combat  support  and  combat 
service  support  units. 

(b)  Producing  detailed  quantitative  data  for  use  in  comparing 
the  effectiveness  of  the  alternative  forces. 

(c)  Simulating  high  and  mid-intensity  conflict  (nuclear  and 
conventional  war) . 

(2)  Operational  Scope.  The  DIVWAG  Model  scope  is  defined  in  terms 
of  command  levels,  military  services,  types  of  operations,  geographical  areas 
of  operations,  rate  of  operation,  and  combat  functions. 

(a)  Command  Levels.  The  DIVWAG  Model  has  been  designed  to 
produce  data  to  evaluate  division  forces;  i.e.,  a  division  plus  an  appropriate 
slice  of  corps  or  field  army  troops.  There  is  explicit  representation  of  the 
task  organization  of  the  forces.  Echelons  of  command  are  defined,  and  reports 
are  prepared  that  reflect  the  status  of  each  command  echelon  and  Include  the 
aggregated  status  of  all  subordinate  units.  Communications  are  simulated 
between  division,  brigade/regiment,  and  battalion  command  units.  A  total  of 
1000  units  can  be  played,  divided  among  Red  and  Blue  forces.  These  units 
must  be  structured  into  task  organizations  for  each  force. 

(b)  Military  Services.  The  DIVWAG  Model  has  been  designed  to 
accommodate  and  integrate  all  types  of  land  forces  (e.g.,  armored,  mechanized, 
and  airmobile)  and  supporting  tactical  air  forces. 

(c)  Types  of  Operations.  The  DIVWAG  Model  provides  for 
representation  of  the  major  types  of  military  operations;  i.e.,  offensive, 
defensive,  retrograde  (delay /withdrawal) ,  covering  force,  and  movement.  In 
addition  the  model  is  capable  of  simulating  high  and  mid-intensity  conflict 
(nuclear  and  conventional  war) . 

(d)  Geographical  Area  of  Operations.  The  DIVWAG  Model  can 
accommodate  rectangular  geographical  areas  as  large  as  8,000  kilometers  on  a 
side.  The  system  is  limited  in  its  application  to  worldwide  geography  only 
by  availability  of  appropriate  input  data. 

(e)  Rate  of  Operation.  The  rate  of  operation  of  the  DIVWAG  war 
game  is  not  firmly  established.  It  is  estimated  that  the  simulation  model 
can  produce  game  period  turnaround  data  in  a  2:1  ratio  of  computer  time  to 
combat  time  simulated  for  a  relatively  straightforward  combat  situation  at  a 
battalion  level  of  resolution.  Actual  timing  is  a  function  of  the  level  of 
resolution  being  gamed,  the  number  of  units  being  gamed,  the  level  of  military 
activity  portrayed,  and  the  nature  of  other  computer  jobs  on  the  system  when 
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the  model  is  being  used  in  a  multiprogramming  environment.  Considering  the 
time  required  for  period  turnaround,  a  real  time  to  game  time  pace  of  approxi¬ 
mately  5:1  is  considered  reasonably  attainable  for  gaming  at  a  sufficient 
level  of  complexity  to  provide  useful  results. 

(f)  Combat  Functions.  The  DIVWAG  Model  can  address  the  following  , 
functions  and  evaluate  the  contribution  to  force  effectiveness  of  varying  the 
mixes  of  related  elements: 


1. 

2. 

and  communications 


Intelligence  functions;  surveillance  and  target  acquisition. 

Command,  control,  and  communications  functions;  decision 
delay  times. 


3..  Firepower  functions. 

U.  Mobility  functions;  aerial,  ground,  and  firepower  mobility. 

5.  Combat  service  support  functions;  supply  and  transportation, 
loss,  expenditure,  and  consumption  rates;  personnel  replacement. 

c.  System  Components.  The  DIVWAG  system  comprises  four  components: 
facilities,  equipment,  personnel,  and  the  gaming  model. 

(1)  Facilities.  The  USACDC  War  Game  Facility,  Building  391,  at 
Fort  Leavenworth,  Kansas,  contains  six  fully  equipped  game  rooms  and  other 
related  supporting  facilities;  see  Figure  1-2  for  floor  plan.  The  US  Army 
Training  and  Doctrine  Command  Data  Processing  Field  Office  (TRADOC  DPFO) 
is  located  In  Building  136',  approximately  1  mile  from  the  War  Game  Facility, 
and  the  Post  Data  Processing  Facility  (PDPF)  in  Building  50  at  about  the 
same  distance. 


(2)  Equipment.  Three  general  types  of  equipment  are  required: 
administrative,  automatic  data  processing,  and  visual  data  display. 

(a)  Administrative  Equipment.  Routine  types  of  administrative 
equipment  are  provided  by  the  War  Game  Facility;  e.g.,  electric  typewriters, 
reproduction  equipment  (Xerox  and  Ozalid  machines).  Related  supplies  are 
required. 


(b)  Automatic  Data  Processing  Equipment.  The  DIVWAG  Model 
software  programs  are  written  in  FORTRAN  for  use  in  the  CDC  6500  SCOPE 
Operating  System.  Required  computer  and  auxiliary  equipment  are  shown 
in  Figure  1-3. 
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Equipment 

Requirement 

Core  storage  capacity 

124,000  words  (octal) 

Magnetic  tape  drives 

2 

Magnetic  disk  capacity 

3,000,000  words  (decimal) 

Printer 

1 

Card  reader 

1 

Software  features 

FORTRAN  compiler  (ANSI)* 
Overlay  loader  (2  levels) 
Mass  storage  input/output 

*American  National  Standards  Institute,  Inc. 


Figure  1-3.  DIVWAG  Computer  Configuration 


One  card  punch  machine  and  one  verifier  are  available  in  the  War  Game 
Facility.  The  other  required  equipments  are  available  in  either  the  TRADOC 
DPFO  or  the  PDPF.  Related  supplies  are  required. 

(c)  Visual  Data  Display  Equipment.  Each  game  room  and  the 
conference  room  in  the  War  Game  Facility  is  equipped  with  two  projection 
stations  and  two  7  ft  x  8  ft  translucent  glass  screens.  The  photographic 
room  is  equipped  for  photography  and  production  of  transparencies.  Related 
maps  and  photographic  supplies  are  required. 

(3)  Personnel.  The  personnel  necessary  for  the  effective  and 
efficient  operation  of  DIVWAG  are  organized  as  shown  in  Figure  1-4.  The 
DIVWAG  organization  consists  of  a  directorate  and  four  operating  elements. 
General  functions  of  these  elements  are  indicated  below. 

(a)  Directorate.  The  Directorate,  consisting  of  the  Game 
Director  and  a  Deputy  Director/Technical  Advisor,  provides  operational  and 
technical  direction  for  the  war  game  staff  and  establishes  operating  policies 
The  Directorate  prepares  the  Game  Plan  which  provides  overall  guidance  for 
the  conduct  of  the  war  game. 

(b)  Model  Maintenance  Team.  The  model  maintenance  team  operates 
maintains,  and  modifies  the  DIVWAG  Model  as  required  to  meet  gaming  require¬ 
ments  and  to  permit  effective  dynamic  gaming.  In  addition  this  team  advises 
the  gaming  staff,  as  necessary,  on  the  technical  rules  of  the  DIVWAG  Model. 
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(c)  Gaining  Staff.  The  gaming  staff,  outlined  by  dashed  lines 
in  Figure  1-4,  consists  of  control  and  player  (Blue  and  Red)  teams. 

Normally,  the  gaming  staff  as  depicted  in  Figure  1-4  can  play  one  open  game. 

1.  Control  Team.  The  control  team  is  the  Game  Director's 
staff  and  consists  of  the  chief  controller  and  the  Red  and  Blue  controllers. 

The  control  team  consists  of  personnel  who  participate  in  the  play  of  a  war 
game  with  the  responsibility  of  controlling  the  play  in  accordance  with  the 
rules  and  predetermined  objectives  through  arbitration  and  assessment  of  the 
actions  and  interactions  of  the  players.  In  addition,  the  technical  aides 
who  assist  the  gaming  staff  in  the  posting  of  maps,  coding  of  data  processing 
cards,  and  maintenance  of  game  records  are  provided  from  the  control  team. 

j2.  Player  Teams.  The  player  teams,  consisting  of  Red  and 
Blue  players,  are  the  participants  in  a  war  game  who  are  not  members  of  the 
control  team  and  who  play  the  roles  of  a  real  world  commander  or  staff 
officers  of  a  military  unit  or  units. 

(d)  Analysis  Team.  The  analysis  team  consisting  of  operations 
research/ systems  analysis  (OR/SA)  specialists  prepares  the  Analysis  Plan  and 
conducts  the  analysis  described  therein.  This  group  identifies  requirements 
for  side  analysis  and  ensures  that  the  appropriate  data  are  being  produced 
through  the  conduct  of  the  game  for  an  evaluation  of  the  game  objectives. 

(e)  Support  Group.  The  support  group  provides  the  bulk  of 
permanent  staffing  required  for  the  administrative  and  logistical  support 

of  the  gaming  effort.  This  support  consists  of  keypunching,  typing,  graphical 
services,  administration,  and  security. 

d.  Gaming  Model.  Functionally  the  DIVWAG  Model  is  a  dual  system;  it 
functions  physically/electronically  as  a  data  processing  system  and,  at  the 
same  time,  it  functions  in  simulation  as  a  military  combat  system.  To  be 
complete,  a  description  of  the  model  must  consider  both  aspects.  The  DIVWAG 
Model  is  described  herein  in  terms  of  its  data  processing  functional  components 
and  its  military  simulation  functional  capabilities. 

(1)  Data  Processing  Functional  Components.  The  DIVWAG  software  is 
divided  functionally  into  five  processors  that  communicate  with  each  other 
through  common  files  and  records.  Designations  and  functions  of  these 
processors  are: 

(a)  Constant  Data  Input  Processor.  The  Constant  Data  Input 
Processor  receives  data  on  cards,  edits  the  data,  and  assembles  the  data  onto 
tape  and  disk  files. 

(b)  Orders  Input  Processor.  The  Orders  Input  Processor  receives 
player  operational  orders  in  semi-military  language  and  processes  these  orders 
into  detailed  instructions  to  the  units  simulated. 
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(c)  Period  Processor.  The  Period  Processor  receives  translated 
player  orders  and  simulates  the  military  action. 

(d)  Period  Output  Processor.  The  Period  Output  Processor 
receives  results  from  the  Period  Processor  and  compiles  specific  reports  and 
gross  summary  reports. 

(e)  Analysis  Output  Processor.  The  Analysis  Output  Processor 
receives  detailed  data  from  the  Period  Processor  as  period  history  tapes; 
retrieves,  arrays,  and  performs  the  statistical  analysis  of  the  data;  and 
outputs  the  arrayed  data  in  specified  formats. 

(2)  Military  Simulation  Functional  Capabilities.  The  Period 
Processor  simulates  an  extremely  broad  and  flexible  spectrum  of  military 
activity  through  four  categories  of  models  (intelligence  and  control,  fire¬ 
power,  mobility,  and  combat  service  support).  The  models  are  described 
individually  in  the  following  subparagraphs. 

(a)  Intelligence  and  Control  (INC).  This  model  provides  the 
quantitative  data  necessary  for  evaluation  of  the  contribution  of  sensor 
mixes  to  force  effectiveness.  It  integrates  the  closely  related  functions 
of  surveillance;  target  acquisition;  combat  intelligence;  and  command,  con¬ 
trol,  and  communications.  Gamers  are  permitted  to  input  intelligence  from 
sources  not  simulated  by  model  components.  The  information  obtained  from 
sensors  and  from  gamer  input  is  processed  and  used  automatically  by  the  INC 
Model  to  make  requests  for  fire  support  on  acquired  targets.  Fire  missions 
are  requested  from  available  attack  helicopters.  Air  Force  close  air  support 
(CAS),  or  ground-based  artillery  by  use  of  a  set  of  decision  rules,  according 
to  the  situation.  Sensor  information  is  also  converted  into  general  intelli¬ 
gence  by  this  model  to  produce  a  summary  report  at  the  end  of  each  game 
period.  The  summary  outlines  the  current  status  of  what  may  be  known  at 
division  level  concerning  the  size,  type,  and  location  of  the  enemy  forces  in 
the  battle  area.  This  report  is  to  aid  the  gamer  in  preparing  orders  for 
the  next  game  period.  The  INC  Model  consists  of  three  interrelated  submodels: 
Collection,  Processing,  and  Decision.  The  military  functions  simulated  by 
the  INC  Model  are  summarized  below  and  include: 

,1.  Sensing  and  Reporting.  The  capabilities  of  individual 
ground  and  aerial  sensors  are  considered  to  simulate  the  detection  and  col¬ 
lection  of  information  or  intelligence  on  units  of  the  opposing  force  and  the 
summarizing  of  such  information  into  sensing  reports,  which  enter  the  intelli¬ 
gence  chain.  Both  target  and  nontarget  intelligence  are  simulated.  Type 
sensors  modeled  include  MTI  radar,  UGS  fields,  countermortar  and  counterbattery 
radar,  air  defense  radar,  visual  observers  in  LOH  and  fixed  wing  reconnaissance 
aircraft,  surveillance  aircraft  (Mohawk  type)  with  MTI  radar  capability,  and 
high  performance  reconnaissance  aircraft  with  visual  and  various  photographic 
capabilities. 
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_2 .  Time  Delays.  The  model  introduces  separate  delays  for 
time  consumed  in  each  of  the  principal  steps:  intelligence  collection, 
intelligence  analysis,  routing,  and  use  of  the  information  in  decisions. 

.3.  Development  of  Targets  for  Fire  Missions.  A  separate 
channel  for  development  of  target  intelligence  is  simulated  by  the  model.  » 

This  channel  provides  acquired  targets  for  fire  missions  without  the  relatively 
long  delays  involved  in  general  intelligence  processing. 


U.  Intelligence  Analysis  and  File  Maintenance.  Comparison 
of  a  new  report  with  information  already  in  the  intelligence  files  is  simu¬ 
lated,  and  if  reports  relate  to  the  same  unit  they  are  consolidated.  The 
existence  of  new  units  or  parent  units  can  be  deduced.  Intelligence  analysis 
centers  are  simulated  for  each  unit  at  maneuver  battalion,  brigade  or  regi¬ 
ment,  and  division  levels.  Files  are  designed  to  stay  within  the  limits  of 
10,  20,  and  100  reports,  respectively,  for  these  three  echelons. 


5^.  Decisions  on  Information/ Intelligence  Flow  and  Requests 
for  Fire  Support.  The  routing  of  information  or  intelligence  among  intelli¬ 
gence  analysis  centers  and  command  elements  at  the  three  echelons  is  simulated 
with  the  use  of  a  flow  structure  and  set  of  routing  criteria,  according  to  the 
information  in  each  report.  A  similar  set  of  criteria  is  used  to  determine 
whether  a  target  qualifies  for  fire  support  and  what  type  of  fire  support 
(attack  helicopter,  TACAIR,  ground-based  artillery)  will  be  requested. 


:> 


b.  Contents  of  Intelligence  Report.  The  eud-of-period 
contents  of  the  division  intelligence  file  are  used  for  thfs  report.  Each 
report  that  met  criteria  to  reach  this  file  and  was  not  discarded  from  the 
file  in  favor  of  a  more  recent  record  or  consolidated  into  a  record  of  a 
parent  unit  is  reflected  in  the  Intelligence  Report.  Items  of  estimated 
information  given  in  the  report  for  each  opposing  unit  in  this  intelligence 
file  include  size,  activity,  type,  direction  of  last  move,  time  last  sensed, 
and  number  of  sensings  attributed  to  this  unit. 

(b)  Firepower  Models.  The  firepower  models  provide  the  ^ 

quantitative  data  necessary  for  evaluation  of  force  effectiveness  as  a  ** 

function  of  changes  in  mixes  and  types  of  major  weapon  systems.  The  models 
integrate  all  aspects  of  mid  or  high  intensity  combat  where  interaction  of 
opposing  forces  may  occur  and  result  in  personnel  or  materiel  losses.  The 
firepower  models  coordinate  and  integrate  the  effectiveness  of  combined  arms 
teams  by  modifying  assessment  routines  for  high  attrition  events  to  account  * 
for  concurrent  and  parallel  killing  capabilities.  For  example,  when  units 
are  engaged  in  combat,  kills  are  related  to  the  number  of  fire  elements  on 
opposing  sides.  Should  an  attack  helicopter  fire  team  make  an  attack  during 
a  ground  combat  cycle,  the  ground  combat  cycle  will  be  interrupted  immediately  % 
prior  to  the  helicopter  attack,  the  status  of  the  units  in  ground  combat  will 
be  updated  to  that  moment,  the  effects  of  the  helicopter  attack  on  the  current 
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ground  combat  unit's  status  will  be  assessed,  and  the  ground  combat  cycle 
will  be  resumed.  The  same  assessment  technique  is  followed  for  other  inter¬ 
facing  firepower  activities.  Five  models  simulate  the  firepower  function: 
Ground  Combat,  Area  Fire,  Nuclear  Assessment,  Air  Ground  Engagement,  and 
TACFIRE.  Each  of  the  first  four  of  these  models  assesses  damage  inflicted 
and  produces  loss,  expenditure  rate,  and  consumption  data  for  use  in  evalu¬ 
ating  the  supply  and  transportation  systems.  The  TACFIRE  Model  works  in  con¬ 
junction  with  the  Area  Fire  Model  to  schedule  fire  on  targets  of  opportunity. 

1.  Ground  Combat  Model: 

a.  The  Ground  Combat  Model  represents  the  interaction 
between  the  direct  fire  weapons  of  opposing  maneuver  units  engaged  in  ground 
combat . 


b^.  The  model  represents  the  interaction  and  the  effects 
of  weapons  of  cross-reinforced  units.  Combat  power  may  be  enhanced  by  employ¬ 
ing  combined-arm  forces  against  the  enemy.  The  effectiveness  of  the  maneuver 
unit  is  largely  dependent  on  the  combination  and  coordination  of  weapon  sys¬ 
tems  within  the  unit.  The  distance  of  separation  of  weapon  systems  is  limited 
so  that  mutual  support  is  possible  when  weapon  density  permits. 

£.  The  impact  of  the  environment  is  represented  by  the 
model.  All  movement  in  ground  combat  is  subject  to  the  constraints  imposed 
by  the  environment  wherein  ability  to  move  forces  by  ground  is  degraded  by 
the  effects  of  adverse  weather,  terrain,  and  visibility.  The  application  of 
firepower  is  largely  controlled  by  the  environment  since  effectiveness  of 
each  weapon  system  is  limited  by  its  associated  target  acquisition  capabilities. 
Target  acquisition  cannot  occur  unless  line  of  sight  exists  between  the  observer 
and  target.  Line  of  sight  may  be  severely  limited  due  to  terrain  roughness, 
vegetation,  and  forestation.  A  firer  may  lose  line  of  sight  on  a  moving  tar¬ 
get  before  firing  a  round.  A  moving  target  may  drop  out  of  line  of  sight 
during  the  time  of  flight  of  the  round.  Target  acquisition  is  limited  by 
visibility,  whether  due  to  adverse  weather  or  night  combat  operations.  Under 
conditions  of  reduced  visibility,  target  acquisition  is  enhanced  by  the 
employment  of  night  vision  equipment. 

<1.  The  interaction  of  each  maneuver  unit  with  the  enemy 
is  considered  by  the  model  in  terms  of  a  maneuver  unit's  effectiveness  and 
vulnerability.  The  maneuver  unit's  effectiveness  is  influenced  by  the  level 
of  activity.  As  the  level  of  activity  increases,  more  weapon  systems  can 
acquire  targets.  As  Individual  moving  weapon  systems  stop  to  fire,  the  signa¬ 
ture  (i.e.,  evidence  of  that  weapon  firing)  increases  with  the  level  of  acti¬ 
vity.  The  maneuver  unit's  vulnerability  is  influenced  by  the  level  of  activity. 
A  firing  weapon  system  may  disclose  its  position  and  become  a  target  for  enemy 
fire. 
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&•  The  Ground  Combat  Model  relies  heavily  on  the 
existence  of  data  to  describe  weapon/ammunition  effectiveness  against  varying 
target  types  in  a  combat  situation.  The  model  also  requires  adequate  data 
to  describe  the  target  acquisition  capabilities  of  all  employed  sensor  types 
other  than  unaided  vision. 

2.  Area  Fire  and  TACFIRE  Models.  The  Area  Fire  and  TACFIRE 
Models  simulate  the  scheduling  of  nonnuclear  munitions  for  area  fires,  and 
delivery  and  assessment  of  results  of  nonnuclear  fires.  Area  fire  events  are 
generated  by  two  methods.  First,  gamers  issue  fire  orders  prior  to  the  en¬ 
gagement  period  for  fire  with  specific  ammunition  at  specific  coordinates.  * 

Second,  during  the  engagement  period  target  information  is  developed  by  the 
Intelligence  and  Control  Model  with  a  request  for  nonnuclear  artillery  fire, 
and  the  TACFIRE  Model  automatically  schedules  the  required  fire  missions  for 
the  fire  units.  The  automatic  mode  is  referred  to  as  the  TACFIRE  mode.  Tar¬ 
gets  in  this  mode  consist  of  targets  of  opportunity  and  are  limited  to  those 
enemy  units  detected  and  processed  by  the  Intelligence  and  Control  Model. 

Fire  units  are  battalion  or  battery  size,  and  integral  fire  units  are  used  in  j 

attacking  area  fire  targets.  The  fire  units  are  constrained  by  range  limita-  ' 

tions,  volley  firing  times,  number  of  tubes  or  rails  per  fire  unit,  and  weap¬ 
ons/munitions  availability.  A  target  threat  priority  value  ranging  from  one 
to  nine  is  assigned  to  each  area  fire  target,  and  is  based  upon  its  estimated 
size,  type,  activity,  range,  and  the  tactical  doctrine  used  in  artillery 
employment  for  the  particular  game.  Priority  one  is  a  higher  priority  than 
priority  two,  etc.  If  a  backlog  of  targets  exists,  targets  are  engaged  in 
highest  priority  order.  The  Area  Fire  routines  are  separated  into  three  func¬ 
tional  classes:  scheduling,  delivery,  and  assessment.  Most  of  the  routines 
for  the  automatic  TACFIRE  mode  are  concerned  with  scheduling  of  fires.  The 
delivery  routines  deliver  the  munitions  on  target  and  determine  units  whose 
presence  in  the  impact  area  will  require  assessments.  The  assessment  routines 
then  calculate  the  effects  of  the  fire  events,  based  on  number  of  rounds  fired, 
lethal  area  of  nonnuclear  munitions,  dimensions  of  the  target,  number  and 
density  of  target  elements,  and  target  vulnerability.  The  assessment  routine 
makes  adjustments  in  target  personnel  and  equipment  to  reflect  losses  and  in 
the  fire  unit's  munitions  on  hand  to  reflect  expenditures.  ^ 

■*.» 

_3.  Nuclear  Assessment  Model.  The  Nuclear  Assessment  Model 
simulates  the  delivery  of  and  the  assessment  of  results  of  tactical  nuclear 
fires.  All  nuclear  fires  are  conducted  in  response  to  gamer  fire  orders, 
issued  prior  to  the  simulated  engagement  period.  The  gamer  fire  order  speci¬ 
fies  the  unit  to  fire,  weapon  and  munition  to  fire,  yield,  height  of  burst  (if  • 
controllable),  and  designated  ground  zero.  Thus,  all  planning  of  nuclear  fires 
must  be  carried  out  by  the  gamer  prior  to  an  engagement  period.  In  response 
to  a  nuclear  fire  order,  the  Nuclear  Assessment  Model  simulates  the  actual 
firing,  the  nuclear  detonation,  and  the  assessment  of  effects  against  all  units 
as  well  as  on  obstacles  and  facilities  within  the  effects  area  of  the  round.  a 
The  detonation  and  effects  of  atomic  demolition  munitions  (ADM)  are  also  sim¬ 
ulated  by  the  model.  Simulated  effects  include  those  due  to  blast,  prompt 
nuclear  and  thermal  radiation,  and  delayed  effects  due  to  induced  radiation. 
Fallout  effects  are  not  simulated. 
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4_.  Air  Ground  Engagement  Model.  The  Air  Ground  Engagement 
Model  simulates  for  both  opposing  forces  all  air-to-ground  and  ground-to-air 
interactions  falling  within  the  definition  of  close  air  support  (CAS)  and 
otherwise  directly  related  to  ground  combat  operations.  These  operations 
include  aircraft  fires  provided  by  other  Services,  and  Army  aircraft  deli¬ 
vering  direct  aerial  fires  (DAF) .  The  Air  Ground  Engagement  Model  determines 
all  attrition  and  casualty  results  of  such  interactions.  The  Air  Ground 
Engagement  Model  is  sufficiently  flexible  that  major  changes  in  aircraft 
characteristics,  quantity  or  mixes  of  the  major  weapon  systems,  or  their  modes 
of  employment  will  be  reflected  in  the  measures  of  force  effectiveness.  Single 
or  multiple  aircraft  flights  are  generated  by  the  Intelligence  and  Control 
Model  or  are  directed  by  gamer  orders.  Attrition  of  aircraft  while  in  flight 

is  based  on  the  location  of  air  defense  capable  units;  i.e.,  units  that  con¬ 
tain  air  defense  weapons.  The  Air  Ground  Engagement  Model  divides  the  flight 
path  into  the  following  segments  as  appropriate:  air  base  to  safe  point, 
safe  point  to  target,  target  to  safe  point,  and  safe  point  to  air  base.  The 
Air  Ground  Engagement  Model: 

.  Selects  from  available  aircraft  and  munitions  types  those  best 
suited  for  the  mission,  determines  the  time  required  for 
aircraft  preparation  and  pilot  briefing,  and  schedules  the 
time  for  aircraft  to  be  airborne. 

.  Maintains  a  current  status  record  for  aircraft  assigned  to  a 
mission,  to  include  munitions  and  POL,  aircraft  losses 
caused  by  enemy  activity,  and  effects  of  the  aircraft  on 
enemy  targets. 

.  Moves  the  aircraft  progressively  along  the  mission  segments, 
assessing  aircraft  status,^  attrition,  and  accomplishments 
at  the  completion  of  each  segment  to  determine  if  the 
mission  should  continue. 

.  Determines  the  results  of  attacks  on  targets  in  terms  of 
aircraft  losses  and  target  losses. 

.  Upon  completion  of  the  mission  and  return  to  the  airbase, 

aggregates  total  mission  results  (including  total  mission 
time),  assesses  aircraft  damage,  and  determines  delay 
times  for  subsequent  mission  availability  of  the  aircraft. 

_5.  Suppression  Model.  The  treatment  of  suppressive  effects 
of  area  fires  or  aerial  strikes  upon  a  unit  was  introduced  to  the  DIVWAG 
Model  through  the  addition  of  a  Suppression  Model.  This  model  represents 


6.  Includes  effects  of  air  defense  activities,  weather,  and  terrain. 
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suppressive  effects  by  the  interruption  of  selected  activities  (unit  movement, 
delivery  of  area  fires,  delivery  of  air  defense  fires)  in  response  to  incoming 
fire.  Length  of  interruption  depends  on  the  activity  interrupted  and  nature 
of  fire  received,  and  the  interruption  is  extended  as  fires  continue  to  be 
received . 


(c)  Movement  Model.  The  Movement  Model  represents  unit  movement  . 
other  than  airmobile  operations  including  the  effects  of  those  activities 
that  serve  to  improve  or  impede  movement.  The  Movement  Model  provides  the 
quantitative  data  necessary  for  evaluation  of  force  effectiveness  as  a  func¬ 
tion  of  ground  movements,  and  the  related  effects  of  significant  changes  in 
the  mixes  and  types  of  mobility  means.  The  Movement  Model  considers  the 
following  aspects  of  force  mobility: 

_1.  Air  Movement.  The  Air  Movement  section  of  the  model 
simulates  moves  by  aircraft  not  in  connection  with  airmobile  operations.  Air 
movements  may  be  ordered  externally  by  gamers  or  generated  internally  by  the 
Air  Ground  Engagement  Model.  Aircraft  availability,  Class  IIIA  supplies,  and 
weather  limitations  are  checked  before  the  air  movement  is  allowed.  Air  routes  j 
altitudes,  and  speeds  are  specified  by  the  gamer  order  or  are  determined  by 
the  model  generating  the  movement  internally.  Once  the  air  movement  is  ini¬ 
tiated,  it  will  be  completed  unless  terminated  due  to  losses.  At  the  end  of 
each  flight  segment  the  unit  will  be  updated  to  reflect  losses  of  aircraft 
and  personnel  and  the  status  of  associated  supplies. 

2_.  Ground  Movement.  The  Ground  Movement  section  of  the 
model  simulates  moves  by  surface  transportation.  Ground  movements  of  units 
not  engaged  in  combat  are  ordered  by  gamers.  Ground  movements  are  affected 
by  category  of  move,  unit  mission,  formation  type,  vehicle  mobility  charac¬ 
teristics,  terrain  conditions,  daylight  or  darkness,  road  nets,  weather, 
natural  obstacles,  and  enemy  created  conditions.  The  maximum  movement  rate 
for  a  unit  is  the  rate  of  the  slowest  type  vehicle  in  the  unit.  Some  of  the 
other  characterist  cs  of  ground  movement  are  indicated  below. 

a..  Administrative/Supply  Movements.  Administrative 
routes  are  generated  by  gamer  orders;  supply  routes,  by  he  Combat  Service 
Support  Model.  The  road  movement  rate  depends  on  road  tyre,  grade,  weather 
conditions,  and  nighttime  or  daytime  conditions.  Administrative  movements 
are  executed  in  segments  determined  by  terrain  cell  boundaries  or  en  route 
obstacles.  Units  are  halted  by  events  scheduled  for  the  moving  unit  and  by 
encountering  obstacles.  After  the  delay,  the  unit  is  not  able  to  make  up 
this  lost  time  but  continues  to  move  at  its  appropriate  rate.  „ 

l>.  Tactical  Movements.  Tactical  routes  are  generated  by 
gamer  orders  and  are  executed  in  segments  in  the  same  manner  as  administrative 
movements.  Starting  times  and  normal  tactical  movement  rates  are  specified 
for  each  unit  type  for  attack,  withdrawal,  and  reinforcing  missions,  as  well  * 
as  for  day  or  night  movements.  Units  are  halted  for  obstacles  or  minefields. 

After  such  delay,  tactical  units  attempt  to  make  up  the  lost  time,  and  move 
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at  the  limiting  mobility  class  rate  for  that  purpose.  The  limiting  mobility 
class  rate  depends  on  terrain  roughness  and  vegetation,  slope  and  soil  traffic- 
ability,  forestation,  weather  conditions,  and  nighttime  or  daytime  conditions. 
Each  equipment  type  is  assigned  to  a  mobility  class,  and  only  those  mobility 
classes  used  during  tactical  movements  are  considered  for  determinirg  the 
limiting  mobility  class. 


£.  Maneuver  Movements.  Maneuvering  weapon  systems  execute 
their  movements  at  maximum  limiting  mobility  class  rates.  Since  different 
weapon  systems  have  different  maximum  rates,  and  since  the  movement  rate  of  a 
maneuvering  unit  is  limited  by  the  rate  of  the  slowest  weapon  system,  faster 
weapon  systems  have  periods  of  time  when  they  are  stationary.  Maneuver  move¬ 
ment  is  controlled  entirely  by  the  Ground  Combat  Model,  which  determines 
detection  capabilities,  vulnerability,  and  weapon  system  capabilities. 

_3.  Stay  Activity.  The  model  also  simulates  stationary 
activities  for  all  gamed  units  not  engaged  in  other  specified  activities;  i.e., 
all  units  that  are  not  performing  another  military  activity  such  as  firing, 
moving,  or  combat.  Whether  or  not  addressed  by  gamer  orders,  an  inactive 
game  unit  will  consume  Classes  I  and  III  supplies  and  can  be  assessed  as 
to  losses  and  status;  other  units  can  gain  information  about  the  inactive 
unit.  If  a  unit  has  completed  all  its  orders  before  the  end  of  a  game  period, 
the  unit  will  automatically  stay  until  the  end  of  the  period.  Stay  activity 
orders  can  be  written  to  command  ground  units  to  remain  in  position  for  a 
specified  length  of  time  or  until  a  specified  game  time  arrives. 

U_.  Engineer.  The  Engineer  Model  simulates  the  scheduling 
and  execution  of  engineer  activities  associated  with  the  construction  and 
destruction  of  obstacles  and  facilities.  The  model  accepts  engineer  tasks, 
assigns  task  priorities,  determines  task  feasibility,  mobilizes  mission  units 
to  execute  the  tasks,  simulates  the  engineering  activity  in  terms  of  time  and 
material  resources  used,  and  demobilizes  the  mission  units. 

a.  Obstacles  and  facilities  are  parts  of  an  overall 
barrier  plan  developed  for  the  game  being  conducted.  Engineering  activities 
can  be  initiated  by  gamer  order  to  start  work  on  a  specified  obstacle  or 
facility  or  by  request  from  the  Movement  Model  when  some  engineering  activity 
is  necessary  for  the  conduct  of  a  directed  movement.  Where  the  engineer 
activity  is  requested  by  the  Movement  Model,  the  moving  unit  is  unable  to 
complete  its  move  until  the  engineer  activity  is  completed. 

]).  Engineer  task  priorities  are  based  primarily  upon  the 
urgency  of  the  activity  in  terms  of  its  impact  on  the  force's  overall  plan 
of  maneuver.  Task  feasibility  is  determined  in  terms  of  task  site  (proximity 
to  FEBA)  and  time  and  materiel  availability. 

£.  The  Engineer  Model  automatically  allocates  resources 
to  each  feasible  task,  constructs  a  mission  unit  to  execute  the  task,  moves 
the  mission  unit  to  the  task  site,  simulates  the  initiation  of  work  when 
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sufficient  resourc. s  are  on  site,  periodically  updates  task  status  until 
completion  of  the  task  (or  until  a  gamer  order  to  stop  the  task  is  encountered! 
and  returns  the  mission  unit  to  its  origin. 

(d)  Airmobile  Model.  The  Airmobile  Model  permits  simulation  of 
a  variety  of  airmobile  operations.  To  maintain  a  high  degree  of  flexibility 
in  application  of  the  model,  the  simulation  depends  upon  the  gaming  staff  for 
most  of  the  general  planning  and  decision  making  prior  to  execution  of  an 
airmobile  operation.  These  plans  are  relayed  to  the  model  by  a  set  of  DSL 
orders.  Activities  actually  simulated  within  the  model  include  allocation  of 
transport  and  escort  aircraft  to  conduct  the  operation,  staging  and  loading 
of  the  airmobile  force,  the  actual  airmobile  movement,  attrition  of  the  air¬ 
mobile  column  while  in  flight  to  and  from  the  objective  area,  suppression  of 
air  defenses  by  escort  aircraft,  deplaning  at  a  landing  zone,  refueling  and 
rearming  of  aircraft,  and  the  release  of  aircraft  from  operational  control  of 
the  airmobile  force. 

(e)  Combat  Service  Support  Model.  This  model  simulates  the 
resupply  of  manpower  and  materiel  to  units  within  the  DIVWAG  system.  The 
model  deals  with  personnel  replacements,  replacement  of  major  items  of  equip¬ 
ment,  and  resupply  of  critical  consumables  such  as  food  (Class  I),  fuel  (Class 
III  and  IIIA) ,  barrier  materials  (Class  IV),  and  ammunition  (Class  V). 

_1.  Replacement  of  personnel  and  major  items  is  accomplished 
once  for  each  simulated  day  of  combat.  Availability  of  replacement  personnel 
and  major  end  items  is  on  a  daily  basis,  input  by  the  gamer,  with  available 
assets  accumulating  over  time;  i.e.,  assets  not  used  on  previous  days  are 
available  in  addition  to  those  available  for  the  current  time.  Requirements 
are  based  on  unit  losses,  represented  by  the  authorized  unit  level  of  personnel 
and  major  items  less  the  quantities  on  hand  within  the  unit  at  the  time  of  the 
replacement  action.  First  priority  for  replacements  and  major  end  items  is 
to  front  line  maneuver  units,  second  priority  to  reserve  maneuver  battalions 
and  all  artillery  units,  and  third  priority  to  all  other  units.  If  sufficient 
replacements  or  major  end  items  are  not  available  to  fill  the  needs  within 
a  unit  priority  group,  each  unit  receives  a  pro  rata  share  of  available  re¬ 
sources  based  on  amounts  required  by  all  units  within  the  priority  group. 
Replacements  and  major  end  items  arrive  at  the  receiving  units  after  an  appro¬ 
priate  travel  delay. 

2.  The  treatment  of  resupply  of  consumables  within  the  Combat 
Service  Support  Model  is  conceptually  similar  to  treatment  of  replacement  of 
personnel  and  major  items.  Implementation  differs  to  account  for  the  following 

ji.  No  limitation  is  placed  on  quantities  of  consumables 
available  to  the  force.  In  the  case  of  consumables,  the  primary  limiting 
factor  is  the  availability  of  transportation  to  move  the  materiel  from  various 
supply  points  to  the  consumer.  The  model  treats  movement  of  consumables 
through  a  series  of  supply  points  from  the  nominal  point  of  entry  into  the 
force  to  the  using  unit.  The  model  uses  either  a  unit  distribution  or  a  supply 
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point  distribution  method  on  each  leg  of  the  supply  chain,  depending  upon  the 
supply  class  of  the  consumable  and  the  nature  of  the  receiving  unit  at  each 
node. 


1).  To  accomplish  a  more  continual  flow  of  consumables, 
resupply  requirements  are  determined  and  actions  initiated  on  a  more  fre¬ 
quent  basis  than  with  replacements.  The  model  currently  uses  a  2-hour  cycle 
for  all  consumables  except  Class  I,  which  is  on  a  once-a-day  cycle.  (As 
experience  is  gained  with  the  model,  some  appropriate  cycle  between  the  ex¬ 
tremes  of  hourly  and  daily  requirement  determination  should  be  established.) 

£.  A  request  for  resupply  of  consumables  is  generated 
if  the  quantity  in  the  unit  trains  is  less  than  a  fixed  percentage  of  the 
authorized  amount  in  trains.  That  percentage  is  currently  set  at  fifty 
percent. 


CHAPTER  2 


GAME  OPERATIONS 


1.  PURPOSE.  The  purpose  of  lis  chapter  is  to  describe  the  management, 
planning, and  operations  necessary  to  conduct  a  force  analysis  using  the 
Division  War  Game  (DIVWAG)  Model. 

2.  GAME  DIRECTIVE.  The  preparation  of  a  Game  Directive  by  a  sponsoring 
agency  requesting  the  use  of  the  DIVWAG  Model  in  support  of  a  force  analysis 
study  is  a  critical  element  in  the  initial  preparation  for  task  execution. 

a.  The  game  sponsor  must  ensure  that  he  communicates,  through  the  Game 
Directive,  the  intent  and  purpose  of  the  force  analysis  study  and  the  nature 
of  the  expected  results.  The  game  and  analysis  objectives  must  be  clearly 
and  succinctly  stated  in  the  Game  Directive  provided  by  the  sponsoring  agency. 
The  number  and  complexity  of  game  and  analysis  objectives  bear  a  direct 
relationship  to  the  study's  chances  of  success.  Lt.  Gen.  Julian  J.  Ewell 
(then  Major  General  and  Deputy  Commanding  General,  U.S.  Army  Combat  Develop¬ 
ments  Command)  wrote: 

If  a  major  study  directive  asks  ten  or  fifteen  major  questions,  its 
chances  of  a  successful  ending  are  heavily  compromised  before  it 
gets  underway.  Every  effort  should  be  made  to  narrow  a  study  down 
to  one  major  question,  with  four  probably  the  absolute  maximum  for 
a  reasonable  effort  and  result.  The  narrowing  can  only  take  place 
after  considerable  thought  as  there  are  usually  many  (apparently) 
logical  alternatives  or  options.  However,  after  much  screening 
effort,  the  supercilious,  redundant,  inconsistent,  or  secondary 
questions  can  be  determined  and  either  eliminated  or  placed  in  a 
category  to  be  answered  only  if  time  permits....  Another  facet  of 
the  same  problem  is  the  habit  of  mixing  large  and  small  issues  in 
a  directive.  This  makes  a  study  most  difficult.  A  big  issue 
usually  requires  a  "big  grain"  study  approach,  a  small  issue  a 
"small  grain"  approach.  Mixing  them  may  require  two  studies  in 
effect  or  a  rather  feeble  cut  at  the  less  important  one. 

b.  The  responsibility  for  the  success  or  failure  of  a  study  (and  the 
attendant  credit  or  discredit)  rests  ultimately  with  the  sponsoring  agency; 
thus,  the  sponsor  is  vitally  interested  in  conducting  a  scientifically  and 
militarily  valid  study  and  in  obtaining  wide  acceptance  of  study  results. 

Task  objectives  that  are  too  numerous  or  complex  to  be  addressed  within 
study  resources  or  that  do  not  adequately  reflect  the  intended  purpose  of  the 


1.  Letter,  CDCDG  to  Chief  of  Staff,  USACDC,  dated  12  February  1968, 
Subject:  Informal  Thoughts  on  Study  Management  at  the  USACDC  Level. 
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analysis  can  only  lead  to  unsatisfactory  results.  Game  managers  can  help  to 
avoid  this  outcome  and  to  achieve  a  mutually  beneficial  end  by  thoroughly 
coordinating  their  analysis  of  game  objectives  with  the  study  sponsor  and  by 
suggesting  redefinition  or  reorientation  of  objectives  when  appropriate;  how¬ 
ever,  the  game  sponsor  cannot  abdicate  his  responsibility  to  pose  the  study 
problem  within  realistic  parameters  and  to  establish  game  objectives  that 
fairly  define  that  problem. 

c.  The  Game  Directive  as  a  minimum  must  contain  the  following  information: 
.  Purpose  and  objectives  of  the  game 
.  Forces  to  be  played 
.  Environment 

.  Force  missions  to  include  scenarios  and  operation  orders 
.  Guidance  such  as: 

-  type  of  game  (open  or  closed) 

-  period  of  game 

-  data  base  to  be  used 

-  assumptions  to  guide  the  game/analysis 

-  guidelines  for  play  of  the  game 

-  doctrine 

.  Results  required 
.  Administration 

An  example  of  a  Game  Directive  containing  the  information  described  above  is 
at  Appendix  B,  Game  Directive  for  WAGCAF  Test  Game,  Volume  VII,  WAGCAP  Testing 
Report. 

3.  GAME  CONCEPT: 

a.  The  ability  of  management  to  understand  the  problem  to  be  solved,  to 
design  a  methodology  for  its  solution,  and  to  develop  a  plan  for  the  timely 
and  efficient  execution  of  the  methodology  is  fundamental  to  the  success  of 
any  force  analysis. 
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(1)  The  problem  to  be  solved  must  be  analyzed  in  terms  of  the 
objectives  or  purposes  of  the  entire  effort,  anticipated  use  of  the  study 
results,  and  the  resources  available  for  application  to  the  study. 

(2)  Once  the  study  problem  is  understood  and  clearly  defined,  an 
appropriate  and  efficient  methodology  for  its  solution  must  be  selected  or 
designed.  The  methodology  must  be  appropriate  in  terms  of  providing  useful 
answers  or  insights  to  the  study  problem  and  efficient  in  terms  of  making 
the  best  possible  use  of  resources  within  the  constraints  of  the  study. 

(3)  After  the  problem  and  methodology  are  well  defined,  the 
development  and  application  of  a  management  plan  become  of  paramount  importance. 
The  plan  must  provide  for  efficient  use  of  personnel  resources,  must  consider 
calendar  time  constraints,  and  must  ensure  that  the  study  effort  maintains 

its  direction  and  that  the  results  are  integrated  to  fulfill  study  objectives. 

b.  The  application  of  the  Division  War  Game  Model  to  an  analytical  task 
consists  of  three  distinct  phases: 

.  Initial  preparation  for  task  execution 

.  Production  of  evaluation  data 

.  Application  of  analytical  methodologies . 

Figure  2-1  presents  the  time  sequence  of  these  three  phases,  each  of  which  is 
discussed  in  following  paragraphs. 

4.  INITIAL  PREPARATION  FOR  TASK  EXECUTION.  The  receipt  of  a  Game  Directive 
from  the  sponsoring  agency  initiates  preparation  for  task  execution.  During 
this  phase,  effort  must  be  directed  at  several  facets,  including: 

.  Development  of  the  Game  Plan 

.  Development  of  the  Analysis  Plan 

.  Collection  and  loading  of  the  constant  input  data. 

a.  Development  of  a  Game  Plan.  The  conduct  of  a  war  game  using  the  DIVWAG 
Model  must  be  preceded  by  a  detailed  analysis  of  the  factors  that  are  critical 
to  game  operations  and  the  subsequent  development  of  a  Game  Plan. 

(1)  Analysis  of  Game  Objectives.  The  analysis  of  game  objectives  must 
include  an  appreciation  of  the  intended  use  of  the  analysis  results.  By  re¬ 
maining  aware  of  the  potential  applications  of  study  results  through  all  phases 
of  study  performance,  management  can  help  to  ensure  that  the  final  product  of 
the  analysis  meets  the  sponsor's  needs. 
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(2)  Design  of  a  Methodology.  The  selection  of  a  methodology  by  which 
the  objectives  will  be  fulfilled  is  one  of  the  most  crucial  elements  in  a 
division  force  analysis.  The  methodology  must  be  appropriate  to  the  problem, 
able  to  be  performed  within  task  resources,  and  capable  of  fulfilling  task 
objectives.  The  steps  include: 

(a)  Selection  of  Measures  of  Effectiveness  and  Effectiveness 

Indicators: 


1.  The  primary  measures  of  effectiveness  (MOEs),  or  the 
criteria  upon  which  the  forces  will  be  evaluated,  should  be  apparent  from  the 
analysis  of  task  objectives.  A  faulty  selection  of  the  primary  MOEs  reflects 
an  incomplete  understanding  of  the  objectives  and  can  seriously  degrade  study 
acceptability  since  the  primary  MOEs  provide  the  basis  for  the  entire  eval¬ 
uation.  On  the  other  hand,  the  secondary  MOEs  and  effectiveness  indicators 
supporting  the  primary  MOEs  must  be  chosen  from  a  wide  range  of  possibilities; 
their  selection  entails  value  judgments  as  well  as  a  careful  analysis  of  the 
components  of  the  primary  MOEs. 

2^.  Chapter  2  of  Analytical  Methodologies^  contains  a  detailed 
discussion  of  the  selection  of  an  MOE  hierarchy  to  support  a  division  force 
analysis.  The  primary  MOE  is  designated  as  mission  accomplishment,  and  second¬ 
ary  MOEs  are  designated  for  each  of  the  functional  areas  of  land  combat.  Ef¬ 
fectiveness  indicators  supporting  each  secondary  MOE  are  chosen  on  the  basis 
of  quantifiable  data  considered  pertinent  to  the  analysis  of  force  effective¬ 
ness  in  each  functional  area  represented  by  the  secondary  MOE. 

3^.  Management  must  emphasize  the  importance  of  the  MOE 
hierarchy  as  the  basis  for  the  analysis  methodology.  Its  selection  requires 
careful  and  thorough  study  by  analysts  familiar  with  the  forces  to  be  evaluated, 
the  doctrine  and  tactics  to  be  employed,  and  the  evaluation  objectives.  The 
MOEs  and  effectiveness  indicators  selected  must  be  coordinated  with  the  sponsor 
and  his  review  board  to  ensure  that  they  adequately  reflect  the  desired  study 
emphasis. 


(b)  Definition  of  Performance  Data  Requirements.  The  definition 
of  performance  data  requirements  is  an  outgrowth  of  the  selection  of  MOEs  and 
effectiveness  indicators.  The  data  necessary  to  quantify  the  MOEs  and  effec¬ 
tiveness  indicators  for  all  units  or  systems  of  interest  under  a  prescribed 
range  or  combination  of  conditions  constitute  the  performance  data  required 
for  the  analysis.  Management  depends  upon  the  game  sponsor  to  provide  the 
parameters  for  the  evaluation  through  a  scenario  and  other  guidance;  staff 
analysts  then  determine  performance  data  needed  to  conduct  the  complete  eval¬ 
uation  based  on  the  MOEs  and  effectiveness  indicators  and  produce  the  Analysis 
Plan  to  accomplish  the  evaluation. 


1.  Development  of  a  Division  War  Game  Model  (DIVWAG) .  Analytical 
Methodologies  (Volume  II),  USACDC  Combat  Systems  Group  study,  December  1971. 
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(3)  Analysis  of  Critical  Game  Factors.  Within  the  framework  of 
resource  constraints  imposed  by  the  Game  Directive,  management  then  identifies 
and  conducts  an  analysis  of  critical  game  factors.  Critical  factors  will  vary 
from  game  to  game,  but  they  typically  include: 

(a)  Game  Requirements.  Game  requirements  Include  the  number  of 
games  to  be  played,  the  number  of  game  days  to  be  played,  and  the  specific 
type  engagements  required. 

(b)  Game  Content.  Game  content  refers  to  such  elements  as  the 
forces  to  be  gamed,  the  level  of  resolution  and  degree  of  aggregation,  organi¬ 
zational  and  equipment  considerations,  and  battle  termination  criteria. 

(c)  Staff  Requirements.  A  representative  listing  of  the  skills 
required  by  a  war  game  includes  the  following: 

1.  Management : 

.  Game  director 

.  Deputy  director/technical  advisor  (operations  research) 

2.  Technical : 

.  Military  analyst 
.  Operations  research  analyst 
.  Systems  analyst 
.  Computer  programmer 
.  Editor 

.  Technical  assistant 
Support: 

.  Administrator 
•  Keypunch  operator 
.  Clerk/ typist 

.  Document  control  clerk 
.  Graphic  arts  technician. 

The  number  of  assigned  individuals  in  each  skill  category  will  vary  from  game 
to  game.  For  some  games,  two  or  more  skills  may  be  provided  by  one  individual 
(e.g.,  an  operations  research  analyst  may  double  as  a  computer  programmer). 
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For  other  games,  several  individuals  of  similar  skills  will  be  needed  to 
perform  a  particular  function. 

(d)  Model  Operation.  This  factor  includes  the  characteristics  of 
the  models  to  be  used,  consideration  of  use  of  component  submodels  in  a  simu¬ 
lation  mode,  and  man/machine  interfaces. 

(e)  Time  Constraints.  The  analysis  of  critical  time  constraints 
will  consider  the  size  of  the  force  to  be  gamed,  the  number  of  game  days  to  be 
played,  calendar  time  allocated,  computer  running  time  to  game  time  ratio, 
game  period  turnaround  time,  manning  levels  and  skills  available,  and  analysis 
requirements. 

(f)  Game  Operation.  The  war  game  is  conducted  after  due 
consideration  of  the  impacts  of  all  other  critical  factors  and  results 
generally  in  the  cycle  scheduling  required  for  the  timely  completion  of 
dynamic  game,  analysis,  and  documentation  effort. 

b.  Preparation  of  the  Game  Plan.  After  completion  of  the  analysis 
described  above,  management  prepares  a  Game  Plan  to  guide  the  staff  effort 
through  the  conduct  of  the  game.  The  Game  Plan  should,  if  at  all  practicable, 
be  coordinated  with  the  game  sponsor  to  ensure  that  the  game  will  be  conducted 
in  a  manner  which  will  produce  the  results  desired  by  the  sponsor.  Figure  2-2 
is  an  outline  for  a  typical  Game  Plan.  It  shows  major  paragraph  headings  and 
gives  a  brief  description  of  the  type  information  to  be  included  under  each 
heading.  The  Game  Plan  consists  of  three  basic  sections — Game  Setting; 
Methodology,  Rules,  and  Procedures;  and  Staff  Organization — which  are  discussed 
in  the  following  subparagraphs. 

(1)  Game  Setting.  This  section  of  the  Game  Plan  provides  the  staff 
with  all  essential  information  concerning  the  game  objectives,  the  scenario, 
the  general  and  special  situations,  and  general  guidance  regarding  collection 

of  data.  It  may  include  administrative  information,  such  as  security  procedures 
and  a  reference  list. 

(2)  Methodology,  Rules,  and  Procedures.  The  general  methodology  and 
the  interface  with  the  analytical  effort  described  in  the  Analysis  Plan  is 
documented.  Rules  are  fixed  constraints  that  determine  the  nature  of  inputs 
to  the  game,  the  handling  of  these  inputs  with  the  gaming  model,  and  the 
resultant  outputs  of  the  model.  Game  rules  and  procedures  play  a  vital  role 
in  the  conduct  of  a  war  game.  They  are  acquired  from  the  Game  Directive,  the 
Game  Plan,  the  model  (in  this  case  the  DIVWAG  Model),  and  from  the  Chief 
Controller  as  a  result  of  his  responsibility  to  ensure  that  the  game  is 
controlled  in  an  orderly  process  to  ensure  achievement  of  game  objectives. 

Rules  may  be  of  two  types,  game  rules  and  technical  rules.  A  thorough  under¬ 
standing  of  the  rules  inherent  to  the  conduct  of  any  specific  game  is  essential 
to  a  valid  interpretation  of  the  results  of  that  game. 
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GAME  PLAN 


Section  I.  GAME  SETTING 


1.  PURPOSE 

A  statement  that  the  game  plan  is  the  basic  document  providing  policy, 
procedural,  organizational,  and  administrative  guidance  for  the 
conduct  of  all  game  phases. 

2.  STATEMENT  OF  THE  PROBLEM 

A  concise  statement  of  the  job  to  be  performed. 

3.  GAME  OBJECTIVES 

A  statement  of  the  specific  game  objectives  as  interpreted  from  the 
game  directive  issued  by  the  sponsoring  activity. 

4.  SCENARIO 

A  description  of  the  conflict  situation  to  be  gamed. 

5.  GENERAL  SITUATION 

A  description  of  the  geographical  and  political  environment  for  the 
conflict  to  be  gamed. 

6.  SPECIAL  SITUATIONS 

A  special  situation  description  for  each  force  to  be  gamed  (Red  and 
Blue)  and  the  disposition  and  missions  of  each  force.  Contains 
privileged  information  and  is  issued  only  to  the  appropriate  player 
team  and  the  control  team. 

7.  REFERENCES 

A  listing  of  documents  to  be  used  in  data  base  preparation  and  as 
doctrinal  guidance  for  the  Red  and  Blue  forces  to  be  evaluated. 

8.  SECURITY 

Standard  operating  procedures  for  handling  classified  defense 
information,  privileged  information  within  the  game,  and  visitors 
and  physical  security  at  the  war  game  facility. 


Figure  2-2.  Sample  Game  Plan  Outline  (continued  next  page) 


Section  II.  METHODOLOGY,  RULES,  AND  PROCEDURES 


9.  METHODOLOGY 

Describes  the  general  methodology  and  interface  with  the  analytical 
effort  described  in  the  Analysis  Plan. 

10.  RULES 

a.  Doctrinal 

Describes  rules  on  doctrine.  Particularly  pertinent  when  new 
and  untested  concepts,  force  structures,  and  equipments  are  gamed. 

b.  Operational 

Describes  rules  derived  from  concepts  and  doctrine.  Impacts 
particularly  on  comparability  in  a  project  requiring  comparison 
of  forces  in  different  games. 

c.  Technical 

Rules  reflecting  model-dependent  considerations. 

11 .  PROCEDURES 

a.  Game  Cycle 

Procedures  to  be  applied  in  conducting  an  entire  game  cycle  (as 
distinguished  from  a  computer  cycle).  Defines  game  cycle  in  terms 
of  beginning  and  ending  point  and  explains  schedule  for  completion 
of  a  normal  cycle.  Particularly  important  in  keeping  project  on 
programmed  calendar  schedule. 

b .  Gaming  Rate 

Provides  schedule  of  game  cycles  in  terms  of  physical  effort  of 
game  turnaround  and  average  game  time  per  cycle. 

c.  Levels  of  Resolution/Aggregation 


d.  Side  Analyses/Sensitivity  Tests 


Procedures  for  side  analyses  and  sensitivity  tests,  if  such 
requirements  are  identified  pregame. 

e.  Critical  Events 

Any  military  phenomenon  of  the  battlefield  the  occurrence  of  which 
results  in  a  decided  advantage  for  one  of  the  protagonists. 
Explains  requirements  to  game  such  events  arising  from  game  direc¬ 
tive  or  from  deduction  resulting  from  preliminary  force  analysis. 

f.  Personnel  Schedules  and  Roles 

Describes  any  peculiar  scheduling  or  personnel  requirements,  such 
as  an  irregular  work  schedule  for  a  particular  period  because  of 
computer  hour  allocation. 

g.  Computer  Interface 

Establishes  procedures  for  assembly  of  game  cycle  turnaround  data 
into  machine  readable  format  and  prescribes  gaming  element 
responsible  for  assembly,  delivery  to  and  pickup  from  the 
computer,  and  the  associated  records  of  the  entire  process. 

h.  Records  Requirements 

Listing  of  all  game  records  to  be  maintained  and  the  responsible 
element. 

i.  Quality  Assurance 

Identifies  responsible  game  elements  and  responsible  individuals 
by  position  title. 

Section  III.  STAFF  ORGANIZATION  AND  OPERATION 

Gives  staff  organization  and  associates  individual  staff  members  with 
position  titles;  may  include  detailed  job  descriptions  and  instructions. 


Figure  2-2.  Sample  Game  Plan  Outline  (concluded) 


(a)  Game  rules  are: 


1_.  Rules  derived  from  concepts  and  doctrine  for  the  employment 
of  forces  and  systems  being  gamed  (doctrinal  rules). 

2_.  Rules  for  the  conduct  of  military  operations  during  the 
game,  or  for  making  decisions  concerning  such  operations  (operational  rules). 

(b)  Technical  rules  are: 


1_.  DSL  rules  which  relate  to  the  use  of  the  basic  DIVWAG 
Scenario  Language  (DSL). 


2_.  Model  rules  which  pertain  to  variables  within  the  computer 
programs  that  cannot  be  adjusted  without  modification  to  the  program. 

(c)  Procedures  are  those  administrative  controls  employed  to  ensure 
an  orderly  sequence  of  events  in  gaming  processes  and  to  extract  maximum 
efficiency  from  the  available  resources. 


(3)  Staff  Organization  and  Operation.  This  section  of  the  Game  Plan 
describes  the  organization  of  the  staff  for  the  game.  It  should  be  sufficiently 
flexible  to  allow  added  detailed  descriptions  of  the  tasks  of  individual  members 
of  each  group.  Detailed  staff  roles  and  functions  are  described  in  Paragraph 
5a(4),  below.  An  example  of  a  Game  Plan  is  at  Appendix  C,  Game  Plan  for  WAGCAP 
Test  Game,  to  Volume  VII,  DIVWAG  Testing  Report. 

c.  Development  of  an  Analysis  Plan: 


(1)  A  sound  plan  for  analyzing  the  performance  data  produced  by  the  war 
game  model  is  essential  to  the  successful  completion  of  the  study.  A  haphazard, 
poorly-planned,  or  hurried  analysis  can,  at  worst,  discredit  a  study  or,  at 
best,  give  rise  to  charges  that  the  analysis  has  failed  to  exploit  fully  the 
potential  of  the  war  game  output. 


(2)  A  plan  for  analysis  of  out]  at  data  should  provide  for  the 
performance  of  both  subjective  and  quantitative  analysis  and  the  integration 
of  results  into  a  product  responsive  to  task  objectives.  Chapters  2  and  3  of 
Analytical  Methodologies^  describes  a  methodology  for  analyzing  force  perform¬ 
ance  data  to  evaluate  a  single  force  and  to  compare  alternative  forces.  This 
methodology  employs  subjective  judgment  and  statistical  techniques  to  derive 
and  test  inferences  regarding  force  performance  under  a  variety  of  background 
conditions.  Appendix  D,  Analysis  Output  Processor  Users  Guide,  to  this  volume 
provides  instructions  for  the  automated  data  extractor  for  the  DIVWAG  Model. 


(3)  Management  should  ensure  that  an  analysis  plan  is  developed  and 
approved  well  in  advance  of  the  initiation  of  game  play.  Analysis  of  data 
can  then  be  performed  according  to  the  plan  concurrently  with  play  of  the  game. 

T.  Ibid. 
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In  this  way,  analysts  can  monitor  the  adequacy  of  game  output  for  analysis 
purposes  and  can  identify  requirements  for  side  analysis. 

(4)  The  Analysis  Plan  has  no  specified  format  but  should  contain  the 
following  elements  as  a  minimum: 

.  Purpose 

.  Scope 

.  Objectives 

.  Assumptions 

.  Guidelines 

.  Performance  data  requirements  to  include  measures  of 
effectiveness  and  effectiveness  indicators 

.  Analysis  procedures 

.  Documentation  requirements 

.  Administration 

.  References 

An  example  Analysis  Plan  incorporating  all  of  the  above  elements  is  at  Appendix 
D,  Analysis  Plan  for  WAGCAP  Test  Game,  to  Volume  VII,  DIVWAG  Testing  Report. 

d.  Collection  and  Loading  of  Input  Data: 

(1)  The  conduct  of  a  war  game  using  DIVWAG  requires  the  utilization  of 
a  large  data  base  containing  many  thousands  of  data  items.  These  data  must  be 
derived  or  extracted  from  available  sources,  coded,  and  entered  into  storage 
devices.  Volume  II,  Analyst /Programmer  Manual,  provides  a  description  of  the 
data  required  as  input  by  DIVWAG  prior  to  the  conduct  of  a  game  to  produce 
data  for  evaluation,  and  detailed  instructions  for  entering  the  data  onto 
standardized  card  formats  compatible  with  the  programs  that  will  actually  load 
the  data  from  cards  into  the  constant  data  files.  The  collection  of  information 
and  its  loading  as  the  constant  data  for  the  DIVWAG  Model  are  critical  and  time- 
consuming  steps  in  task  preparation.  The  accumulation  of  the  constant  data 
requires  ten  steps: 

(a)  Identifying  input  data  requirements  for  all  submodels. 

(b)  Identifying  data  sources. 

(c)  Obtaining  sponsor  approval  of  data  sources. 


(d)  Obtaining  documentation  from  the  data  sources. 

(e)  Extracting  pertinent  data  and  verifying  that  the  data  are 
appropriate  for  their  intended  use  in  the  particular  submodel  or  file  within 
DIVWAG. 

(f)  Preparing  data  input  forms  (coding  of  data  onto  standardized 

card  forms). 

(g)  Keypunching  of  input  data  cards. 

(h)  Loading  of  input  data  cards  into  the  proper  files  within  the 

computer. 

(i)  Verifying  that  the  data  stored  in  the  constant  data  input  files 
accurately  represent  the  data  transcribed  from  the  documentation  sources  and 
that  they  are  in  consonance  with  the  sponsor's  overall  guidance. 

(j)  Documenting  the  data  base  as  a  portion  of  the  war  game  report. 

(2)  Management  should  be  aware  that  each  of  these  steps  is  time- 
consuming  and  that  difficulties  can  arise,  especially  when  data  must  be 
obtained  for  new  or  conceptual  units  or  systems,  and  should  ensure  that 
the  data  are  gathered  in  accordance  with  a  plan  and  a  stringent  schedule. 

A  potential  for  human  error  exists  at  several  points  in  the  data  preparation 
process,  and  management  should  establish  a  system  of  checks  and  approvals 
to  minimize  the  chanceB  of  a  damaging  data  input  error.  Acceptance  of  the 
final  analysis  product  can  be  jeopardized  by  unacceptable  input  data.  For 
this  reason  management  cannot  overemphasize  the  importance  of  the  data  col¬ 
lection  process  and  its  thorough  coordination  with  the  sponsoring  agency. 

e.  Summary.  The  initial  preparation  for  a  division  force  analysis  is  a 
critical  managerial  assignment.  The  game  manager  must  understand  the  signif¬ 
icance  of  the  problem  and  determine  the  nature  of  the  end  product  required  to 
fulfill  task  objectives.  He  must  ensure  that  the  methodology  designed  for  the 
task  is  complete,  capable  of  being  performed  within  task  resources,  and  respon¬ 
sive  to  task  requirements.  He  must  supervise  the  development  of  a  plan  for 
analysis  of  data  and  must  assemble  and  organize  a  staff  representing  the  requi¬ 
site  skills  for  successful  performance  of  the  entire  study.  Satisfactory  com¬ 
pletion  of  the  study  reots  obviously  with  thorough  management  planning  and 
timely  accomplishment  of  tasks  during  the  preparation  phase. 

5.  PRODUCTION  OF  EVALUATION  DATA.  The  second  phase  of  a  division  force 
analysis  consists  of  three  activities;  i.e.,  pregame  activities,  dynamic 
game  play,  and  poscgame  activities.  The  following  subparagraphs  describe 
the  pregame  and  postgame  activities.  Chapter  3  discusses  the  dynamic  game 
play. 
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a.  Pregame  Activities.  The  pregame  activity  period  is  a  vital  part  of  the 
entire  model  application  process.  Activities  conducted  during  this  period 
include: 

.  Establishment  of  control  procedures 

.  Acquisition  of  facilities,  visual  aids,  supplies,  and  equipment 

.  Revision  of  DIVWAG  Model/data  base 

.  Organization  of  the  staff  for  game  operations 

.  Preparation  for  the  first  game  period. 

(1)  Establishment  of  control  procedures  for  defense  information  as  well 
as  for  game  information  is  an  essential  pregame  activity.  Defense  information 
security  must  adhere  to  the  appropriate  industrial  or  governmental  security 
regulations.  In  addition  to  government  security  handling  procedures,  game 
information  may  have  to  be  distributed  on  a  game  need-to-know  basis.  Control 
procedures  must  be  established  for  game  records.  Vital  analysis  records  must 
be  identified,  and  appropriate  systems  and  procedures  must  be  set  up  to  main¬ 
tain  the  quality  and  integrity  of  these  records.  In  addition,  administrative 
records  are  required  to  assist  in  maintaining  schedules  and  recording  opera¬ 
tional  shortfalls  so  that  improved  game  operational  procedures  can  be  developed. 

(2)  Acquisition  of  facilities,  visual  aids,  supplies,  and  equipment 
must  precede  any  serious  attempt  to  apply  the  DIVWAG  Model.  Working  space  is 
required  for  player  and  control  teams,  support  personnel,  analysts,  and  com¬ 
puter  model  maintenance  personnel.  A  graphic  support  facility,  reproduction 
equipment,  visual  aids,  and  an  appropriate  stock  of  expendables  must  be  pro¬ 
vided  to  support  the  game. 

(3)  In  many  cases,  the  DIVWAG  Model  will  require  some  modifications  to 
make  explicit  a  representation  of  combat  that  may  have  been  treated  implicitly 
before.  If  this  is  not  required,  the  mere  fact  that  a  game  is  ordered  means 
that  previous  games  did  not  adequately  address  the  problem;  thus,  the  data  base 
will  undoubtedly  need  revision.  These  steps  must  be  undertaken  as  early  as 
possible. 

(4)  The  gaming  staff  (depicted  in  Figure  1-4,  Chapter  1,  and  delineated 
in  the  Game  Plan)  should  be  organized  for  dynamic  game  play  during  pregame 
activity.  The  functions  and  responsibilities  of  each  participant  in  the  game 
should  be  clearly  defined.  General  functional  responsibilities  are  described 
below. 

(a)  Game  Director.  The  Game  Director  directs  and  supervises  all 
aspects  of  the  war  game  operations.  His  responsibilities  include: 
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JL.  Interpreting  the  Game  Directive  and  translating  it  into  a 

Game  Plan. 

_2.  Interpreting  current  military  doctrine  and  the  proposed 
doctrine  being  tested. 

J3.  Establishing  operational  and  control  policies  for  gaming 
operations  within  the  constraints  of  policies  provided  by  the  Game  Directive. 

U_.  Functioning  in  the  hierarchy  of  military  units  as  the 
commander  of  the  military  unit  next  superior  to  the  highest  military  unit 
being  gamed.  For  example,  if  the  highest  military  unit  being  gamed  is  a 
division,  he  will  function  in  the  role  of  corps  commander  and  will  provide 
corps  operation  orders  and  intelligence  situation  reports  if  required. 

(b)  Deputy  Director/Technical  Advisor.  The  Deputy  Director/ 

Technical  Advisor  provides  technical  expertise  for  war  game  operations.  His 
responsibilities  include: 

jL.  Providing  to  the  Game  Director  and  all  organizational 
elements  of  the  gaming  staff,  technical  advice  and  assistance  on  the  operational 
aspects  of  the  war  game  model. 

2.  Maintaining  close  liaison  with  the  Analysis  Team  to  assure 
that  data  being  produced  are  adequate  for  evaluations  performed  by  that  group. 

_3.  Coordinating  the  arrangements  for,  and  making  recommendations 
regarding,  side  analyses  and  sensitivity  tests  identified  by  the  Analysis  Team 
as  requirements. 


£.  Monitoring  of  gaming  operations  and  procedures  to  ensure 
that  they  are  in  consonance  with  the  Game  Directive  and  related  directives. 

(c)  Chief  Controller.  The  Chief  Controller  directs,  supervises, 
and  participates  in  the  military  play  as  required  to  provide  effective  gaming 
operations.  His  responsibilities  include: 

^.Translating  the  Game  Plan  into  a  Game  Period  Concept  for 
each  game  period. 

2.  Enforcing  current  military  doctrine  and  proposed  doctrine 

being  tested. 

3.  Conducting  controller  briefings  of  the  Game  Director,  other 
controllers,  and  the  player  teams. 

4,.  Directing  and  participating  in  the  preparation  of  battle 

orders. 
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_5*  Coordinating  the  preparation  of  unit  scenarios. 

_6.  Assembling  and  checking  the  DSL  card  deck. 

2«  Conducting  error  analysis  of  the  Control  Team  portion  of 
the  military  aspects  of  the  data  processing. 

J3.  Interpreting  overall  game  period  results  and  their 

acceptability. 


9_.  Operating  the  Control  Team  game  room  and  maintaining 
related  displays. 

10.  Preparing  and  maintaining  game  records  adequate  to  provide 
a  sound  basis  for  evaluation  of  game  results. 

11.  Directing  and  supervising  the  preparation  of  game  period 

reports. 


(d)  Blue  Controller.  The  Blue  Controller  provides  staff  support 
to  the  Chief  Controller  and  assists  him  in  handling  functions  related  to  Blue 
Team  gaming  operations.  His  responsibilities  include: 

2-  Coordinating  control  matters  affecting  the  Blue  Team. 

2.  Advising  the  Chief,  Blue  Team,  on  operational  matters. 

3.  Assisting  in  the  preparation  of  the  Game  Period  Concept. 


preparation. 

deck. 


4^.  Assisting  in  the  preparation  of  controller  briefings. 

J5.  Assisting  in  the  preparation  of  battle  orders. 

j6.  Preparing  post-battle  instructions  for  Blue  units. 

J7.  Assisting  in  the  coordination  of  Blue  unit  scenario 

£1.  Assisting  in  the  assembly  and  checking  of  the  DSL  card 


9.  Assisting  in  the  error  analysis  of  the  Control  Team 
portion  of  the  military  aspects  of  the  data  processing. 


10.  Assisting  in  the  interpretation  of  game  period  results. 

11.  Assisting  in  the  operation  and  maintenance  of  the  Control 
Team  game  room  and  related  displays. 
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12.  Assisting  in  the  maintenance  of  gaming  records. 

13.  Assisting  in  the  preparation  of  gaming  reports. 

(e)  Red  Controller.  The  Red  Controller  provides  staff  support  to 
the  Chief  Controller  and  assists  him  in  handling  functions  related  to  Red  Team 
gaming  operations.  His  responsibilities  are  identical  to  those  of  the  Blue 
Controller. 

V 

(f)  Technical  Assistant.  The  Technical  Assistant  assists  the 
Control  Group  in  executing  operational  functions  of  a  routine  nature.  His 
responsibilities  include: 

JL.  Assisting  in  the  operation  and  maintenance  of  the  Control 
Team  game  room  and  related  displays. 

2.  Assisting  in  the  maintenance  of  gaming  records  by 
functioning  as  records  controller  for  the  gaming  staff. 

31.  Assisting  in  the  preparation  of  gaming  reports. 

(g)  Records  Clerk/Messenger.  The  Records  Clerk/Messenger  performs 
administrative  duties  for  the  Gaming  Staff.  His  responsibilities  include: 

JL.  Typing  and  reproducing  documents  as  required. 

2.  Assisting  in  the  preparation  of  gaming  reports. 

.3.  Assisting  the  Control  Team  Programmer  in  the  processing  of 
operational  card  decks. 

As  a  messenger,  transporting  card  decks,  work  requests, 
and  printouts  between  the  War  Game  and  the  DPFO. 

5_.  Performing  other  duties  as  assigned. 

(h)  Control  Team  Programmer.  The  Control  Team  Programmer  processes 
operational  card  decks  into  and  out  of  the  War  Game  Facility  and  the  DPFO  and 
stores  and  maintains  operational  decks  as  required  at  the  War  Game  Facility 
during  a  game.  His  responsibilities  include: 

1^.  Receiving  DSL  card  decks  from  the  gaming  staff. 

J2.  Inserting  appropriate  processing  control  cards  into  the 

card  decks. 

_3.  Preparing  processing  request  forms. 

f*.  Logging  card  decks  into  and  out  of  the  War  Game  Facility. 
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Arranging  messenger  service  and  dispatching  card  decks  from 
the  War  Game  Facility  to  the  DPFO. 

Arranging  messenger  service  and  pickup  of  card  decks  and 
printouts  from  the  DPFO  and  delivery  to  the  War  Game  Facility. 

_7.  Receiving  card  decks  and  printouts  at  the  War  Game  Facility. 

ji.  Removing  processing  control  cards  from  the  card  deck. 

9_.  Delivering  printout  to  the  gaming  staff. 

10.  Segregating  and  storing  operational  decks  at  the  War  Game 
Facility  as  required. 

(i)  Blue/Red  Player  Teams.  The  Blue/Red  Player  Teams  play  the 
real  world  role  of  commander  and  staff  of  the  highest  military  unit  being 
gamed;  i.e.,  the  team  directs  the  military  play  of  that  unit  in  consonance  l 

with  the  Game  Period  Concept,  current  force  military  doctrine,  and  proposed 
military  doctrine  being  tested. 

1.  Team  Chief.  The  Team  Chief  directs,  supervises,  and 
participates  in  the  military  play  of  Blue  units  as  required  to  provide  an 
effective  Blue  force  contribution  to  gaming  operations.  His  responsibilities 
include: 


a.  Translating  the  team  portion  of  the  Game  Period  Concept 
into  a  Commander's  Concept  and  Operation  Order. 

lb.  Conducting  team  briefings  to  the  Control  Team. 

£.  Directing  and  participating  in  unit  scenario  preparation. 

id.  Conducting  error  analysis  of  the  force  portion  of  the 
military  aspects  of  the  data  processing.  ^ 

e.  Interpreting  the  force  portion  of  the  game  period 
results  and  their  acceptability  from  the  team  standpoint. 

Operating  and  maintaining  the  team  game  room  and 
related  displays.  » 

jg.  Preparing  and  submitting  team  gaming  records  adequate 
to  provide  a  sound  basis  for  evaluation  of  gaming  results. 

h.  Directing  and  supervising  force  inputs  to  gaming  reports.' 
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2.  Gamer.  The  Gamer  provides  staff  support  to  the  Team  Chief 
and  assists  him  in  handling  functions  related  to  gaming  operations.  His  re¬ 
sponsibilities  include : 

a.  Preparing  staff  estimates. 

b^.  Assisting  in  the  preparation  of  Operation  Orders. 

£.  Assisting  in  the  preparation  of  team  briefings. 

_d.  Preparing  unit  scenarios. 

£.  Assisting  in  the  error  analysis  of  the  force  portion 
of  the  military  aspects  of  the  data  processing. 

f.  Assisting  in  the  interpretation  of  the  game  period 
results  and  their  acceptability  from  the  team  standpoint. 

£.  Assisting  in  the  operation  and  maintenance  of  the 
team  game  room  and  related  displays. 

h.  Preparing  team  gaming  records. 

i.  Preparing  force  inputs  to  gaming  reports. 

(j)  Model  Maintenance  Team.  The  Model  Maintenance  Team  operates, 
maintains,  and  modifies  the  DIVWAG  Model  as  required  to  permit  effective  dyna¬ 
mic  gaming. 


1^.  Chief  Analyst.  The  Chief  Analyst  directs,  supervises,  and 
participates  in  Model  Maintenance  Team  activities  as  required  to  support  ef¬ 
fective  gaming  operations.  His  responsibilities  include: 

£.  Modifying  the  DIVWAG  Model  as  required  to  meet  specific 
requirements  of  the  Game  Directive  and  Game  Plan. 

b^.  Maintaining  and  updating  technical  manuals  and 
programming  manuals  related  to  the  DIVWAG  Model. 

£.  Conducting  technical  error  analysis  of  DIVWAG 
operational  ADP  outputs. 

ji.  Trouble-shooting  and  correcting  technical  problems 
involved  when  the  DIVWAG  Model  does  not  perform  as  expected. 

e.  Designing  and  preparing  control  decks  and  deck 
assembly  instructions  for  processing  input  data  through  the  DPFO. 
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2.  System  Analysts.  The  System  Analysts  assist  the  Chief 
Analyst  in  those  activities  necessary  for  carrying  out  his  functions  and 
responsibilities. 

(k)  Analysis  Team.  The  Analysis  Team  analyzes  game  objectives, 
determines  data  requirements  for  satisfying  the  objectives,  analyzes  gaming 
results  to  determine  that  data  being  produced  are  in  consonance  with  those 
data  requirements,  and  evaluates  gaming  results  in  terms  of  game  objectives. 

The  Analysis  Team  consists  of  Operations  Research  Analysts  and  System  Analysts 
specializing  in  analytical  evaluation  methodology. 

(5)  After  the  staff  is  organized,  the  model  and  data  base  revised, 
facilities  acquired,  and  control  procedures  established,  the  final  step  in 
the  pregame  activities  is  preparing  for  the  first  game  period. 

(a)  The  following  actions  must  be  taken: 

1.  The  Game  Director  will  brief  the  staff  on  the  objectives 
outlined  in  the  Game  and  Analysis  Plans  and  present  his  plan  and  concept  for 
the  conduct  of  dynamic  game  play. 

2..  The  Control  Team  will  prepare  the  Game  Period  Concepts  in 
accordance  with  guidance  in  the  Game  Plan,  and  the  Chief  Controller  will  brief 
the  Game  Period  Concept  to  the  Game  Director. 

2-  The  Control  Team  will  brief  the  Player  Teams  on  the  concept 
for  the  first  period,  and  the  Player  Teams  will  prepare  their  Operation  Plan 
and  Concepts.  To  reduce  the  number  of  briefings,  the  Player  Teams  may  attend 
the  Control  Team  briefing  to  the  Director. 

4..  The  Player  Team  Chiefs  will  brief  the  Control  Team  on  their 
concepts  and  plans  for  the  first  period. 

5^.  The  Player  Teams  will  prepare  their  unit  scenario  input  for 
the  first  period. 

6>.  The  Control  Team  will  prepare  the  battle  orders  and 
integrate  the  team  unit  scenarios  into  the  DSL  deck. 

]_•  The  Model  Maintenance  Team  will  initialize  the  DIVWAG 
system  by  running  a  "ZERO"  period. 

.8.  The  Control  Team  will  prepare  Operating  Instructions  for 
the  first  game  period. 

9.  The  Operating  Instructions  and  DSL  Edit  will  be  processed 
through  the  DPFO. 
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10.  Errors,  if  any,  in  the  DSL  deck  will  be  corrected,  and  a 
DSL  compile  will  be  processed  through  the  ADP  Facility. 

11.  The  first  game  period  will  be  processed  through  the  ADP 

facility. 

(b)  The  procedures  and  techniques  associated  with  the  sequence 
described  above  are  explained  in  Chapter  3  to  this  volume.  The  running  of 
the  first  game  period  signals  the  beginning  of  dynamic  game  play,  the  subject 
of  Chapter  3. 

b.  Postgame  Activities.  When  the  required  evaluation  data  have  been 
accumulated  from  the  dynamic  play  phase,  the  War  Game  Facility  is  placed  on 
an  inactive  status.  At  this  time,  many  of  the  control  procedures  can  be 
lifted.  Postgame  activities  include  completing  records,  providing  indexes 
to  data  tapes  and  output  listings,  and  other  administrative  steps.  The  gaming 
staff  is  often  asked  to  record  their  insights  for  use  in  the  evaluation  of  the 
force  played.  Specific  activities  for  the  gaming  staff  during  this  step  are: 

(1)  Securing  and  indexing  all  records. 

(2)  Preparing  final  report  of  gaming,  including  recommendations  for 
model  improvements  and  game  operation  and  procedures  improvements. 

(3)  Assisting  with  analysis  of  game  data  in  accordance  with  the 
Analysis  Plan. 

6.  APPLICATION  OF  THE  ANALYSIS  METHODOLOGY.  The  third  phase  of  the  division 
force  analysis,  application  of  the  analysis  methodology,  can  begin  as  soon  as 
evaluation  data  are  available  from  the  game.  The  Analysis  Team  augmented  by 
the  gaming  staff  applies  the  procedures  established  by  the  Analysis  Plan  to 
evaluate  performance  data  by  both  subjective  and  statistical  techniques.  The 
results  are  documented,  interpreted,  and  presented  to  the  sponsor  in  terms  of 
the  original  game  objectives.  Management  concern  during  this  final  phase  of 
the  study  effort  is  directed  toward: 

.  Successful  accomplishment  of  the  Analysis  Plan,  especially  the 

integration  of  the  subjective  and  statistical  analysis  aspects 

.  Cogent  presentation  of  the  analysis  results  as  fulfillment  of  the 
study  objectives 

.  Final  achievement  of  a  sound  basis  for  acceptability  of  results. 

a.  Performance  of  the  Analysis  Plan: 

(1)  The  purpose  of  the  Analysis  Plan  is  to  ensure  that  the  analysis 
produces  the  information  required  by  the  game  objectives.  A  research  war  game 
is  played  to  obtain  the  answers  to  difficult  questions.  These  questions  may 
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be  very  specific  or  very  general.  As  an  example,  a  specific  question  might 
concern  the  improvement  in  force  performance  effected  by  a  single  weapon  system, 
and  a  general  question  might  require  a  "yes"  or  "no"  answer  to  whether  Force 
One  is  better  than  Force  Two.  The  Analysis  Plan  ensures  tnat  the  correct  data 
are  analyzed  in  a  form  adequate  to  answer  the  questions  posed  by  the  game 
objectives. 

(2)  While  dynamic  game  play  is  in  progress,  evaluation  analysts  can 
determine  from  game  period  results  the  areas  where  game- generated  data  are 
inadequate  for  satisfying  evaluation  requirements.  These  inadequacies  are 
brought  to  the  attention  of  the  Game  Director,  who  evaluates  them  and  who  may 
then  issue  game-modifying  instructions  as  appropriate.  In  some  cases,  the 
Chief  Controller,  working  within  the  constraints  of  existing  gaming  rules, 
may  be  able  to  manipulate  game  events  or  procedures  in  a  manner  that  will 
produce  the  required  data  without  modifying  the  game  rules. 

(3)  A  war  game  produces  an  overwhelming  mass  of  data  ranging  from  the 
subjective  impressions  of  the  staff  operating  the  game  to  the  straight  report¬ 
ing  of  consumption  and  loss  figures.  In  satisfying  the  game  objectives,  all 
data,  subjective  and  objective,  must  be  integrated  and  synthesized  in  a  manner 
permitting  comprehension.  Subjective  impressions  of  force  performance  are 
combined  with  objective  reporting  of  facts  to  provide  credible  answers  to  the 
study  objectives. 

b.  Presentation  of  Analysis  Results.  A  war  game  has  been  characterized 
as  a  communication  system  in  which  participants  with  different  reference 
frames  are  required  to  comprehend  each  other.  In  the  presentation  of  analysis 
results  this  concept  must  be  extended  to  include  the  game  sponsor;  he  is  a 
node  in  the  communication  system.  Whatever  information  is  obtained  from  the 
analysis  must  be  communicated  with  near  perfect  comprehension.  In  most  cases 
the  game  sponsor  does  not  participate  in  the  game.  He  is,  therefore,  denied 
the  advantage  of  an  education  extending  over  a  considerable  period  of  time,  an 
advantage  enjoyed  by  the  game  participants.  He  has  not  had  the  opportunity  to 
develop  a  common  base  of  understanding  with  the  participants  and  director  of 
his  game;  therefore,  in  the  presentation  of  results,  the  game  director  must 
use  the  sponsor's  from  of  reference.  Generally,  considerable  transformation 
must  be  anticipated;  otherwise,  the  conclusions  of  the  study  may  encounter 
misunderstanding,  hostility,  or  outright  disbelief.  The  burden  is  on  the  game 
director  to  present  results  in  the  language  of  the  sponsor. 

c.  Acceptability  of  Results.  Management  effort  following  the  receipt  of 
the  initial  force  analysis  directive  is  oriented  toward  constructing  a  sound 
methodology  and  performing  a  valid  analytical  effort  as  a  basis  for  achieving 
a  useful,  responsive,  and  scientifically  and  militarily  acceptable  product. 

Each  aspect  of  the  task  is  critical.  The  analysis  of  objectives,  selection 
of  evaluation  tools,  designation  of  measures  of  effectiveness,  and  establish¬ 
ment  of  a  data  base  are  crucial  preparatory  steps.  The  conduct  of  the  game 

by  employing  sound  military  principles  and  using  a  well-researched  and  accept¬ 
able  model  is  fundamental.  The  culmination  of  the  entire  effort,  however,  is 
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the  analysis  of  data  and  the  presentation  of  results.  Management  must  ensure 
that  the  analysis  procedures  are  visible;  i.e.,  that  the  techniques  are  ex¬ 
plained  in  detail  and  that  their  application  at  each  step  of  the  analysis  is 
thoroughly  documented.  The  methodology  then  is  allowed  to  stand  on  its  own 
merits,  and  the  validity  of  the  results  derived  therefrom  is  judged  on  this 
basis.  Effective  management  of  a  successful  force  analysis  is  not  confined  to 
guiding  the  effort  to  a  timely  completion  within  project  resources.  Achieve¬ 
ment  of  a  product  that  reflects  credit  on  management  and  sponsor  alike  relies 
on  an  accurate  visualization  of  the  analysis  problem,  design  and  application 
of  an  appropriate  methodology,  and  a  clear  and  usable  presentation  of  the 
analysis  results. 
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CHAPTER  3 


DYNAMIC  GAME  PLAY 


1.  PURPOSE.  The  purpose  of  this  chapter  is  to  define  the  game  period  opera¬ 
tional  sequence  and  to  describe  the  operational  procedures  and  techniques  of 
dynamic  play  with  the  DIVWAG  Model. 

2.  GAME  PERIOD  OPERATIONAL  SEQUENCE: 

a.  The  use  of  the  Period  Processor  of  the  DIVWAG  Model  in  the  execution 
of  a  war  gaming  project  is  referred  to  as  the  dynamic  game  play  phase.  Dynamic 
game  play  commences  when  all  the  pregame  activities  are  judged  accomplished. 

The  procedural  steps  in  the  operational  sequence  of  dynamic  game  play  consist 
of : 


•  Preparation  of  the  Game  Period  Concept 

.  Conduct  of  Control  Team  briefings 

Game  Director's  briefing 
Player  Team  briefings 

.  Preparation  of  operation  plans  and  concepts 
.  Conduct  of  Player  Team  briefings 

.  Preparation  of  Unit  Scenarios 

.  Preparation  of  Battle  Paragraphs 

.  Establishment  of  computer  interface 
.  Review  and  analysis  of  game  period  output 
.  Maintenance  of  game  records. 

These  procedural  steps  should  be  followed  meticulously  by  a  gaming  staff.  As 
each  gaming  staff  gains  proficiency  in  its  own  operations  and  in  application 
of  the  model,  the  Game  Director  should  establish  his  own  protocol  with  respect 
to  combining  operations  and  procedures  and  in  the  design  of  functions  of 
procedures  not  covered  herein. 


b.  Each  procedural  step  in  the  operational  sequence  of  a  game  period 
cycle  is  described  below  and  is  depictea  in  Figure  3-1.  The  descriptions 
which  follow  reference  Figure  3-1. 
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(1)  The  Control  Team  prepares  a  Game  Period  Concept  (GPC)  for  the 
period  of  the  game  next  to  be  played,  Block  4.  This  concept  is  briefed  to  the 
Game  Director,  Block  5.  The  Game  Director  directs  attendance  at  the  briefing, 
which  should,  as  a  minimum,  include  attendance  of  the  Analysis  Team  and  the 
entire  Control  Team. 

(2)  After  the  Game  Director  approves  the  Game  Period  Concept,  the 
Chief  Controller  presents  the  concept,  along  with  appropriate  guidance,  to  the 
Player  Teams,  Block  6.  In  cases  where  the  Game  Director  modifies  the  Game 
Period  Concept,  these  modifications  are  made  prior  to  implementation  by  the 
Player  Teams. 

(3)  The  Player  Teams  use  the  Game  Period  Concept  and  written  and/or 
verbal  guidance  from  the  Control  Team  in  preparing  their  plans  and  concepts. 
Block  7.  When  both  teams  are  prepared,  each  team  presents  its  concept  and 
plan  to  the  Chief  Controller,  Block  8.  After  the  Chief  Controller  approves 
the  plans,  a  briefing  for  the  Game  Director  is  arranged. 

(4)  The  Control  Team  briefs  the  Game  Director,  Block  9.  As  the  game 
progresses,  these  latter  two  steps  may  be  accomplished  simultaneously  by  asking 
the  Game  Director  to  sit  in  on  the  Player  Team  briefing  to  the  Control  Team. 

(5)  After  the  Player  Team's  concepts  and  plans  are  approved  by  the 
Game  Director  and  the  teams  are  briefed  by  the  Chief  Controller,  Block  10, 
players  prepare  the  Unit  Scenarios,  Block  11,  while  the  Control  Team  prepares 
the  Battle  Paragraphs,  Block  12. 

(6)  Coding  sheets  are  reviewed  by  the  Control  Team  for  obvious  errors 
and  then  sent  for  keypunching  and  verifying,  Block  13.  Punched  cards  are 
returned  to  the  Control  Team.  The  Player  and  Control  Teams  then  assemble  and 
manually  check  the  deck.  Block  14. 

(7)  A  work  request  is  prepared  by  the  Control  Team  Programmer 
requesting  a  DSL  EDIT,  Block  15.  The  Support  Group  handles  the  administrative 
processes  of  taking  the  job  to  the  DPFO  and  returning  the  DSL  EDIT  output, 
broken  line.  Block  16,  to  the  Control  Team,  where  the  DSL  EDIT  is  reviewed  for 
errors,  Block  17.  If  there  are  no  errors,  the  work  request  for  a  DSL  COMPILE 
is  prepared  by  the  Control  Team  Programmer,  Block  19;  the  job  is  taken  to  the 
DPFO  for  processing  and  retrieved  by  the  Support  Group,  broken  line,  Block  20. 

(8)  If  there  are  errors,  the  Control  Team  determines  the  source  and 
initiates  necessary  corrective  action,  Block  18.  Serious  errors  require  a 
recycle  and  a  new  DSL  EDIT.  In  the  case  of  minor  errors,  corrections  are 
inserted  and  a  DSL  COMPILE  work  request  is  prepared,  Block  19. 

(9)  The  Support  Group  repeats  the  steps  necessary  to  take  the  job  to 
the  DPFO  and  return  it  to  the  War  Game  Facility,  broken  line,  Block  20,  where 
the  Control  and  Model  Maintenance  Teams  review  the  DSL  COMPILE  for  errors, 

Block  21. 
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(10)  In  case  of  DSL  COMPILE  errors,  the  Control  Team  goes  through  the 
same  analysis  and  decision  processes  as  for  the  DSL  EDIT,  subparagraph  (8) 
above.  When  all  errors  are  corrected  and  a  good  compile  is  obtained,  a  work 
request  for  an  Operating  Instructions  run  and/or  Period  Processor  run  is  pre¬ 
pared  by  the  Control  Team  Programmer,  Block  22. 

(11)  Again  the  Support  Group  processes  the  job,  broken  line,  Block  23, 
and  returns  the  output  to  the  systems  analysts  at  the  War  Game  Facility. 

(12)  The  systems  analysts  of  the  Model  Maintenance  Team  review  the 
output  for  technical  adequacy.  Block  24.  The  Control  Team  reviews  the  output 
for  operational  acceptability,  Block  25.  The  Player  Teams  assist  the  Control 
Team  with  this  review, 

(13)  If  the  game  period  results  are  unsatisfactory,  a  determination 
is  made  as  to  the  cause,  broken  line.  Block  26;  the  possible  causes  include 
input  errors,  model  logic  errors,  and  system  errors. 

(a)  If  the  cause  is  a  system  error,  the  systems  analysts  in  the 
Model  Maintenance  Team  diagnose,  test,  and  rerun. 

(b)  If  the  cause  is  a  model  logic  error,  it  is  referred  to  the 
Model  Maintenance  Team  for  correction. 

(c)  If  the  cause  is  an  input  error,  a  determination  is  made  as 
to  whether  it  is  a  data  input  or  gamer  order  (DSL)  error.  If  the  latter,  the 
same  processes  are  used  as  those  used  to  review  DSL  EDIT  and  COMPILE.  If  the 
cause  is  a  data  input  error,  corrected  data  input  is  prepared  and  the  data 
are  loaded  into  the  proper  file  within  the  computer. 

(14)  A  new  game  period  cycle  is  initiated  when  a  game  period  run  is 
deemed  satisfactory.  The  Control  and  the  Player  Teams  perform  the  following 
steps.  Blocks  1  through  3,  to  the  degree  possible  using  the  Period  Output 
Reports. 


(a)  Determine  end-of-period  locations  of  maneuver  units, 
ascertain  whether  the  FEBA  has  moved,  and  review  the  end-of-period  personnel 
and  key  equipment  strengths  and  activities  of  maneuver  and  combat  support 
units. 

(b)  Review  the  significant  activities  in  each  battle. 

(c)  Verify  that  planned  moves  of  maneuver  and  combat  support 
units  were  accomplished. 

(d)  Review  the  overall  situation  in  light  of  the  force  mission. 

(e)  The  Control  Team  then  prepares  a  Game  Period  Concept  for 
the  subsequent  period  based  on  the  force  mission,  Block  4;  the  Game  Director 
is  briefed  on  the  game  period  results  and  Game  Period  Concept,  Block  5;  the 
cycle  continues  through  the  steps  previously  discussed. 


(15)  The  foregoing  is  a  description  of  the  routine  procedures  for  a 
single  game  period;  however,  in  order  that  successive  periods  can  be  executed 
smoothly,  two  other  events  are  critical,  as  discussed  below  (see  also  Blocks 
27  and  28,  Figure  3-1). 

(a)  The  game  map  is  posted  to  reflect  game  period  results  as  a 
prelude  to  each  succeeding  period,  and  appropriate  game  period  administrative 
records  are  prepared. 

(b)  As  each  succeeding  game  period  is  turned  around  and  after  a 
successful  DSL  COMPILE  has  been  obtained,  Player  Teams  prepare  a  summary  of 
the  results  of  the  previous  period.  These  summaries  not  only  provide  a  basic 
record  of  the  game  but  also  are  necessary  for  an  understanding  of  game  period 
activities  as  a  prelude  to  analysis  of  game  results. 

c.  The  remaining  paragraphs  of  this  chapter  provide  procedures  and 
techniques  for  each  step  in  the  operational  sequence  of  dynamic  game  play. 

3.  PREPARATION  OF  THE  GAME  PERIOD  CONCEPT: 

a.  Introduction: 

(1)  Several  directives  and  references  define  the  environment  in  which 
the  gaming  action  is  to  take  place  and  chart  the  general  course  of  the  action. 
These  directives  include  the  Game  Directive,  the  Game  Plan,  the  Analysis  Plan, 
and  the  Game  Director's  briefing. 

(2)  To  assure  that  the  tactical  situation  will  develop  along  lines 
that  will  carry  the  action  through  all  the  areas  of  study  interest,  it  is 
necessary  for  the  Control  Team  to  monitor  player  orders  continuously  and  to 
adjust  the  situation  when  a  necessary  situation  does  not  appear  to  be  develop¬ 
ing  in  the  natural  course  of  the  play. 

(3)  There  are  several  methods  by  which  the  Control  Team  may  adjust 
the  situation.  First,  the  Control  Team  may  order  some  particular  action  by 
one  or  both  Player  Teams  to  create  a  necessary  situation.  Usually,  the  Red 
Team  is  used  as  the  foil  for  this  purpose,  and  the  Blue  Team  is  left  to  play 
freely  within  the  constraints  of  assigned  missions  and  specified  tactical 
doctrines . 

(4)  Second,  the  Control  Team  may  revise  mission  timetables.  If 
dynamic  play  is  progressing  at  a  slower  pace  than  originally  planned,  missions 
may  be  terminated  early,  or  force  missions  may  be  restated  for  earlier  accom¬ 
plishment. 

(5)  Third,  the  Control  Team  may  inject  into  the  play  intelligence 
information  that  will  lead  the  player  teams  into  the  desired  situation. 
Intelligence  information  play  simulated  internally  in  the  Intelligence  and 
Control  Model  does  not  provide  the  required  output  for  this  purpose. 


3-5 


Intelligence  information  for  this  purpose  is  developed  by  the  Control  Team 
without  use  of  firm  rules;  Control  Team  members  must  rely  upon  their  sub¬ 
jective  judgments  in  creating  this  information. 

b.  Objective.  The  general  objective  of  the  Game  Period  Concept  is  to 
focus  the  military  action  into  a  specific  course  for  the  game  period  in  a  way 
that  will  assure  a  high  probability  that  the  game  period  will  produce  an 
effective  contribution  toward  accomplishment  of  the  game  objectives. 

c.  Purpose.  The  Game  Period  Concept  serves  several  purposes: 

(1)  From  some  aspects  the  Game  Period  Concept  serves  as  the 
commander  of  the  echelon  above  the  major  military  unit  being  gamed. 

(2)  The  Game  Period  Concept  serves  as  a  vehicle  for  providing  Player 
Teams  with  the  following: 

(a)  Orientation  as  to  significant  military  interactions  that  can 
be  expected  to  occur  during  the  period  as  a  natural  outcome  of  the  military 
situation,  or  that  will  be  directed  by  the  Control  Team  in  order  to  better 
align  the  military  action  along  the  desired  course. 

(b)  Information  and  guidance  as  to  likely  critical  events  to 
provide  a  basis  for  Player  Team  planning  for  such  events. 

(c)  Special  instructions  regarding  gaming  methods  and  procedures. 

(3)  The  Game  Period  Concept  provides  a  basis  for  estimating  the  dura¬ 
tion  of  the  gaming  period  in  terras  of  game  tim^  and  for  scheduling  of  activi¬ 
ties  during  the  military  action  preparation  phase  of  the  period. 

(4)  The  Game  Period  Concept  provides  a  vehicle  for  documentation  of 
Control  Team  decisions. 

(5)  The  Game  Period  Concept  provides  a  check  point  for  quality  control 
of  gaming  activity. 

d.  Responsibility.  The  Chief  Controller  is  responsible  for  preparation 
of  the  Game  Period  Concept. 

e.  Format  and  Content.  The  Game  Period  Concept  is  prepared  in  the  format 
and  with  the  content  indicated  in  Figures  3-2  and  3-3.  Details  of  the  content 
are  covered  in  the  next  paragraph,  and  a  sample  of  a  completed  Game  Period 
Concept  is  shown  in  Figure  3-4.  The  Game  Period  Concept  is  first  prepared  as 
a  draft  document  and  remains  in  draft  form  until  final  approval  by  the  Game 
Director. 


GAME  PERIOD  CONCEPT  (GPC) 


Game  Period  _ 

Game  Time  _ 

Classified  Log  No  _ 

Preparation  Schedule 

Complete  GPC  _ 

Start  Control  Briefing  _ 

Start  Control  Instructions 


MILITARY  CONSIDERATIONS 

I.  CURRENT  MILITARY  SITUATION: 

a.  Red 

b.  Blue 

II.  STATUS  OF  GAME  OBJECTIVES: 

a.  Achieved 

b.  Objectlve(s)  of  this  Period 

III.  SIGNIFICANT  MILITARY  INTERACTIONS  FOR  THIS  PERIOD: 

IV.  CRITICAL  MILITARY  EVENTS: 


SYSTEM  CONSIDERATIONS 
I.  STATUS  OF  OPERATIONAL  OBJECTIVES: 

a.  Objective (a)  Achieved 

b.  Objective (s)  for  this  Period 

II.  SPECIAL  CONSTRAINTS 

a.  Removed 

b.  Added 

c .  Unchanged 

INCLOSURES:  "  ~ ”  "  ~ 

_ _  1  -  Instructions  for  Red  Team 

_  2  -  Instructions  for  Blue  Team 


Local  Time  _ 

Duration  this  Game  Period  _  Hrs 

Complete  DSL  Decks 

Complete  DSL  EDIT _ _ 

Complete  DSL  COMPILE  _ _ 


Figure  3-2.  Format  and  Content  of  Game  Period  Concept 
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1 

RED  TEAM 

GAME  PERIOD 

INSTRUCTIONS  FOR 

BLUE  TEAM 

Gone  Period 

Game 

l 

Gene  Time 

Local  Time 

Claaaified  Log  No 

Duration  thia  Game  Period 

Hrs 

Preparation  Schedule 

Complete  GPC 

Complete  DSL  Deck 

Start  Control  Briefing 

Complete  DSL  EDIT 

i 

Stert  Control  Instructions 

Complete  DSL  COMPILE 

i 

_ • 

MILITARY 

CONSIDERATIONS 

t 

I.  STATUS  OF  GAME  OBJECTIVES: 

{ 

i  ii. 
j  in. 

I  IV* 

i 


a.  Achieved 

b.  Objective(a)  for  thia  Period 

SIGNIFICANT  MILITARY  INTERACTIONS  FOR  THIS  PERIOD: 
CRITICAL  MILITARY  EVENTS: 

COORDINATING  INSTRUCTIONS: 


II. 


SYSTEM  CONSIDERATIONS 
STATUS  OF  OPERATIONAL  OBJECTIVES: 

a.  Objective(a)  Achieved 

b.  Objectlve(s)  for  this  Period' 

SPECIAL  CONSTRAINTS : 

a.  Removed 


b.  Added 

c.  Unchanged 


Figure  3-3 


Format  and  Content  of  Instructions  to  Player  Teams 


CAME  PERIOD  CONCEPT  (CPC) 

Cane  Period _ j _ Game  U*GCAP  _ 

Coiw  Time  010930-011130 _ Loca!  Tim-  190800  Apr  72 _ 

Classified  J-og  No  _ _  Duration  this  Cane  Petjod  £ _ Hrs 

Preparation  Schedule 

Complete  CPC  191100  APr  72 _ Complete  DS1.  Peck  191600 _ 

Start  Control  Briefing191100  APr  72  Compete  DSL  EDIT  191600 _ 

Start  Control  lost  ructions  19H3Q  Complete  DSL  COMPILE  19X900 


MILITARY  CON*  S I DE  RAT  IONS 
I.  CURRENT  MILITARY  SITUATION: 
a.  Red 

(1)  Current  status  by  010930  May  1974,  the  Red  attack  on  the  nose  end 
on  the  southern  portion  of  the  penetration  has  been  stopped  and  elements  of 
the  Blue  3d  Armored  Division  have  Initiated  a  counterattack.  The  leading  Red 
tank  regiments  sustained  significant  casualties.  Current  strength  of  key 
Red  tank  battalions  Is  as  Indicated  below: 


Unit 

Tenk  Strength 

Per*  Strength 

1  Bn,  3  Regt,  1  Dlv 

892 

71% 

2  Bn,  1  Regt ,  1  Div 

682 

632 

3  Bn,  3  Regt,  1  Dlv 

302 

23% 

1  Bn,  1  Regt,  2  Dlv 

332 

37% 

2  Bn,  1  Regt,  2  Dlv 

682 

48% 

3  Bn,  1  Regt,  2  Dlv 

752 

73% 

Several  Red  artillery  and  rocket  launcher  units  also  sustained  heavy  losses. 

(2)  Current  plan.  Red  will  conduct  a  limited  withdrawal  In  order  to 
straighten  their  Interior  lines  and  permit  the  most  seriously  damaged  units 
to  break  contact. 

b .  Blue 

(1)  Present  Status. 

(s)  As  of  0930  hours  on  7  May  1974  the  Blue  force  has  halted  the 
Red  advance  and  Is  counterattacking  to  destroy  the  penetration. 


Figure  3-4.  Sample  of  Completed  Game  Period  Concept  (continued 
next  page) 
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(b)  In  the  3d  Annd  Div  1st  Bde  area  the  1-41  Armor  TF  has  sustained 
heavy  casualties,  259  personnel  and  26  tanks,  which  have  reduced  the  unit  to 
522  strength  while  the  1-42  Armor  TF  has  not  reached  the  LD  but  has  lost  10 
personnel  and  1  tank. 

(c)  In  the  2d  Bde  area  the  1-43  Armor  TF  counterattack  is  continuing 
in  the  vicinity  of  the  LD  and  the  unit  losses  have  reached  60  personnel  and 

2  tanks.  The  1-44  Armor  TF  attack  has  crossed  the  LD  and  has  lost  129  personnel 
and  10  tanks. 

(d)  The  personnel  and  tank  status  of  the  counterattacking  TFs  Is 

as  shown: 

Personnel  Tanks 


1-41  Armor  TF 

522 

292 

1-42  Armor  TF 

982 

972 

1-43  Armor  TF 

892 

952 

1-44  Armor  TF 

762 

722 

(2)  Current  plans 

(a)  The  1st  Bde  plans  to  relieve  the  1-41  Armor  TF  with  the  1-51 
Mech  Inf  TF  and  to  counterattack  in  the  Bde  sector  with  the  1-51  Hech  on  the 
left  and  1-42  Armor  TF  on  the  right. 

(b)  The  remainder  of  the  Blue  forces  will  continue  their  present 
missions  in  the  counterattack  effort . 

XX.  STATUS  OF  GAME  OBJECTIVES 

a.  Achieved: 

(1)  Model  Objectives. 

(a)  Demonstrated  the  operability  of  the  DIVWAG  Period  Processor. 

(b)  Demonstrated  the  operability  of  the  Game  Period  Output 

Processor . 

(2)  Training  Objective.  Demonstrated  that  government  personnel  are 
capable  to  act  as  control  and  player  team  members.  All  administrative  suspense 
times  were  met  except  COMPILE  which  was  one  day  late. 

(3)  Military  Objectives.  All  military  objectives  were  met  except  two. 

(a)  Only  the  assault  battalions  of  the  counterattack  force 
effected  a  passage  of  lines.  The  original  objective  should  have  been  so  stated. 

(b)  There  were  no  INC  generated  attack  helicopter  sorties  because 
a  last  minute  decision  was  made  to  RETAIN  all  attack  helicopters. 

b.  Objectives  of  this  Period: 


Figure  3-4.  Sample  of  Completed  Game  Period  Concept  (continued) 
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(1)  Model  Objective.  Demonstrate  an  Improvement  In  the  operability 

of  the  DIVWAC  Period  Processor  In  view  of  the  fact  that  the  first  period  required 
two  weeks  for  a  successful  run. 

(2)  Training  Objective.  Demonstrate  an  Improved  capability  on  the 
part  of  government  personnel  by  meeting  all  suspense  periods  established. 

(3)  Military  Objectives: 

(a)  Having  completed  DSL~dlrected  preparatory  fires,  achieve  credible  game 
rjsuUi^b£t  re  lying  on  systemlcally  generated  fires  by  artillery  and  Air  Force  close 

(b)  Reflect  the  impact  of  Redfs  precarious  situation  by  producing 
data  revealing  his  combat  power  attrition  while  trying  to  consolidate. 

(c)  Reflect  the  masking  of  all  of  Blue  Sth  Mach  Dlv  direct  fires 
except  those  of  the  1st  Bn,  2d  Bde. 

(d)  Depict  a  variety  of  attack,  defend,  delay  situations  which  will 
produce  combat  results  data  for  analysis  purposes. 

III.  SIGNIFICANT  MILITARY  INTERACTIONS  FOR  THE  PERIOD 

a.  Intense  ground  combat  in  Red  2d  Tank  Division  tone. 

b.  Continuation  of  Blue  passage  of  lines  operation. 

c.  Combat  units  on  each  aide  may  be  expected  to  reach  termination  criterion. 
However,  the  Red  situation  dictates  that  no  conditional  termination  criteria  be 
applied  this  period. 

SYSTEM  CONSIDERATIONS 

I.  STATUS  OF  OPERATIONAL  OBJECTIVES 

a.  Objectives  Achieved.  None. 

b.  Objectives  for  this  Period.  Same. 

II.  SPECIAL  CONSTRAINTS 

a.  Removed: 

(1)  No  unit  will  engage  In  more  chan  one  named  battle  at  any  one 

time. 

(2)  Red  fotcea,  except  those  opposing  the  Blue  Id  Armored  Division, 
will  be  attempting  a  firepower  kill  throughout  the  period. 

b.  Added: 


Figure  3-4.  Sample  of  Completed  Game  Period  Concept  (continued) 


(1)  No  DSL-directed  artillery  missions. 

(2)  No  DSL-directed  CAS  sorties. 

(3)  Blue  attack  helicopters  will  be  held  in  a  RETAIN  status. 

(4)  Refrain  from  non-essential  use  of  TRANSFER  orders. 


INCLOSURES : 

_  1  -  Instructions  for  Red  Team 

_  2  -  Instructions  for  Blue  Team 


Figure  3-4.  Sample  of  Completed  Game  Period  Concept 
(concluded) 
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f.  Preparation  Procedures.  The  following  procedures  constitute  a  check 
list  for  rapid  preparation  of  the  Game  Period  Concept. 

(1)  Heading.  Enter  the  first  five  items  of  heading  identification 
information  in  the  Game  Period  Concept  form;  the  remaining  heading  items  will 
be  entered  later. 

(2)  Military  Considerations.  Prepare  and  enter  synopsis  of  body 
information  in  the  Game  Period  Concept  form. 

(a)  Current  Military  Situation.  Summarize  aspects  important  to 
game  objectives;  enter  this  summary  in  the  Game  Period  Concept  form. 

(b)  Status  of  Game  Objectives: 

Review  objectives  of  previous  game  period  and  determine 
if  there  are  any  critical  objectives  yet  to  be  achieved;  summarize  objectives 
achieved  and  enter  this  summary  in  the  Game  Period  Concept  form. 

2.  Based  on  the  results  of  subparagraph  make  selection 
of  objectives  for  this  period  and  summarize  them;  enter  this  summary  in  the 
Game  Period  Concept  form. 

(c)  Significant  Military  Interactions  Planned  for  This  Game 
Period.  A  significant  military  interaction  is  defined  as  a  military  inter¬ 
action  between  opposing  forces  wherein  the  nature  of  the  interaction  must  be 
investigated  in  order  to  provide  data  and  insights  and  inferences  from  which 
can  be  drawn  conclusions  essential  to  the  achievement  of  the  study  objectives. 
Typical  examples  of  significant  military  interactions  include  both  explicit 
and  implicit  requirements;  e.g., 

.  Engagement  of  a  specific  Red  unit  by  a  specific  mix  of 
Blue  artillery.  (Explicit) 

.  Use  of  specific  Blue  atomic  demolition  munitions  in  a 

specific  natural  barrier  line  to  delay  specific  types 
of  Red  units.  (Explicit) 

.  Conduct  a  variety  of  delaying  operations  in  determining 
how  a  given  Blue  division  force  can  best  conduct  a 
delaying  action  from  one  defensive  line  to  another 
defensive  line.  (Implicit) 

,1.  Review  significant  military  interactions  of  previous 

game  periods. 

2.  Summarize  results. 
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3.  Review  scenarios  and  instructions. 


j4.  Based  on  the  results  of  subparagraphs  _1,  2^  and  above, 
plan  significant  military  actions  for  this  game  period  and  summarize  the 
overall  scheme  of  action;  enter  this  summary  in  the  Game  Period  Concept  form. 

5.  Estimate  the  times  at  which  significant  interactions 

will  take  place. 

Estimate  the  game  time  at  which  the  situation  will 
require  player  intervention  to  maintain  game  integrity. 

_7.  Set  the  tentative  duration  of  this  game  period;  enter 
in  the  Game  Period  Concept  form  heading. 

jj.  Advise  the  chief  of  each  Player  Team  of  the  tentative 
duration  of  the  game  period  so  the  team  players  can  begin  preliminary  planning 

j).  Establish  which  individual  Blue  and  Red  military  units 
will  be  involved,  and  make  separate  lists  of  these  units  to  provide  bases  for 
issuing  instructions  and  for  check  list  for  later  review  of  operation  orders. 

(d)  Critical  Military  Events.  A  critical  event  is  defined  as 
any  military  event  likely  to  result  in  at  least  a  temporary  decided  advantage 
to  one  of  the  protagonists,  and  which  advantage,  if  not  countered,  may  become 
decisive.  Typical  examples  of  critical  events  include: 

.  First  employment  of  nuclear  weapons 

.  After  first  employment  of  nuclear  weapons,  a  concentrated 
employment  of  nuclear  weapons 

.  First  encounter  with  a  new  and  highly  effective  weapon 
system 

4 

.  Attacker  penetration  so  rapid  that  defender  must  make  a 
crisis  decision  on  counterattacking,  containing,  or 
withdrawing 

.  Reduction  of  the  military  effectiveness  of  a  unit  to  a 
value  less  than  its  break  point. 

Determine  likely  critical  events  for  the  coming  period.  Establish  which  indi¬ 
vidual  Blue  and  Red  military  units  will  be  involved,  and  make  separate  lists 
of  these  units  to  provide  bases  for  issuing  instructions  and  for  check  list 
for  later  review  of  input  orders. 


(3)  System  Considerations.  Prepare  and  enter  considerations  affect¬ 
ing  the  exercise  of  the  division  war  game  system.  For  this  purpose  the  system 
comprises  the  war  game  model,  the  facilities  in  which  the  model  is  exercised 
(DPFO  and  War  Game  Facility) ,  and  the  game  staff  organization. 

(a)  Status  of  Operational  Objectives.  Enter  those  system  opera¬ 
tional  objectives  established  by,  or  implied  from,  the  Game  Directive. 

_1.  Objectives  Achieved.  Enter  those  system  operational 
objectives  achieved  as  a  result  of  game  play  through  the  close  of  the  preceding 
period.  Examples  of  such  entries  are: 

.  Computer  time-to-combat  time  ratio  is  0.83:1.00; 
objective  is  1.00:1.00.  Objective  exceeded  by 
0.17:1.00 

.  Blue  helicopters  detected  and  killed  Red  tanks 
under  nighttime  conditions. 

2.  Objectives  for  This  Game  Period.  Enter  those  system 
operational  objectives  that  are  expected  to  be  achieved  by  the  execution  of 
this  game  period.  These  may  be  objectives  that  have  not  yet  been  achieved  or 
objectives  that  have  been  achieved  but  for  which  verification  of  achievement 
is  needed.  Examples  of  such  entries  are: 

.  Game  turnaround  time-to  combat  time  ratio  of 

1.00:1.00 

.  Red  missile  units  attack  Blue  targets  in  order  of 
priority;  maneuver  battalions,  command  post,  and 
supply  installation. 

(b)  Special  Constraints.  Prepare  and  enter  any  special 
constraints  to  be  imposed  or  removed  during  this  game  period.  Additionally, 
identify  those  special  constraints  previously  imposed  that  remain  in  effect 
for  this  period.  Examples  of  special  constraints  are  as  follows: 

.  DPFO  will  be  nonoperational  030800-031200  Jan  71  for 
maintenance . 

.  War  Game  RAD  is  accorded  Priority  3  by  USTRADOC. 

.  Camera  equipment  of  the  War  Game  Facility  is 
inoperative  until  080800  Jan  71. 

.  Blue  DSL  FLY  missions  will  penetrate  no  deeper  than 

Weser  River;  RED  AD  task  organization  is  not  loaded 
beyond  that  line. 
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(4)  Inclosures.  Place  X  in  appropriate  space  under  Inclosures. 

(5)  Game  Period  Instructions  for  Team.  In  a  closed  game,  instructions 
to  Player  Teams  are  prepared  separately  for  each  team  and  formatted  as  separate 
inclosures  to  the  Game  Period  Concept.  Except  for  the  coordinating  instruction, 
all  of  the  information  found  in  these  instructions  is  lifted  directly  from  like 
titled  items  of  the  body  information  of  the  Game  Period  Concept  form.  Only 
items  pertinent  to  the  team  addressed  are  included.  Care  must  be  exercised  in 
the  segregation  of  privileged  information  to  prevent  its  disclosure  to  the 
opposing  team. 

4.  CONTROL  TEAM  BRIEFING.  This  operation  involves  two  functional  briefings 
by  the  Control  Team,  one  for  the  Game  Director  and  one  for  the  Player  Teams. 

Each  briefing  is  discussed  separately. 

a.  Control  Team  Briefing  of  the  Game  Director: 

(1)  Purpose.  The  purpose  of  this  briefing  is  to  permit  the  Game 
Director  to  monitor  the  planned  military  action  for  this  game  period  before  it 
is  initiated  in  order  to  determine  if  the  Game  Period  Concept  draft  is  adequate 
and  in  general  consonance  with  the  Game  Plan.  This  briefing  also  provides  a 
check  point  for  quality  control. 

(2)  Responsibility.  The  Chief  Controller  is  responsible  for  conduct¬ 
ing  this  briefing. 

(3)  Attendees.  Based  upon  recommendations  of  the  Chief  Controller, 
the  Game  Director  will  diet  'te  attendance.  Care  should  be  exercised  to  ensure 
Analysis  Team  representation  when  such  team  is  a  part  of  the  war  game  staff. 

(4)  Place.  Normally  this  briefing  will  be  conducted  in  the  Control 
Team  game  room. 

(5)  Decision.  At  the  conclusion  of  the  briefing,  the  Game  Director 

will  decide  if  the  Game  Period  Concept  draft  needs  revision  or  if  it  is  1 

acceptable  as  is. 

(a)  If  the  Game  Period  Concept  draft  needs  revision,  the  Game 
Director  will  instruct  the  Chief  Controller  as  to  the  specific  nature  of  the 
revisions. 

4 

(b)  When  the  Game  Period  Concept  draft  is  finally  acceptable, 
the  Game  Director  will  approve  it;  and  the  action  will  proceed  to  the  briefing 
of  Player  Teams. 

(6)  Documentation.  A  copy  of  the  approved  Game  Period  Concept  will 
be  provided  by  the  Chief  Controller  to  each  element  requiring  it  for  analysis 
purposes . 
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b.  Control  Team  Briefing  of  the  Player  Teams: 

(1)  Purpose.  The  purpose  of  the  briefings  is  to  orient  the  Player 
Teams  in  those  portions  of  the  Game  Period  Concept  draft  pertinent  to  their 
particular  teams  for  this  game  period  to  enable  the  teams  to  prepare  their  own 
operational  concepts  for  the  period  in  consonance  with  the  Game  Period  Concept 
draft.  Except  in  open  games,  separate  briefings  will  be  held  for  opposing 
Player  Teams. 

(2)  Responsibility.  The  Chief  Controller  is  responsible  for  the 
conduct  of  the  briefings.  In  the  interest  of  shortening  game  turnaround  time, 
the  Chief  Controller  may  delegate  to  his  Deputy  Chief  Controller  or  to  Senior 
Controllers,  responsibility  for  the  actual  briefing  presentations;  in  this  way 
the  briefings  for  opposing  teams  may  be  conducted  simultaneously. 

(3)  Attendees.  The  Chief  Controller  will  dictate  attendance. 

(4)  Place.  For  all  games  except  open  games,  briefing  of  the  Blue 
Team  should  be  conducted  in  the  Blue  Team  game  room  and  briefing  of  the  Red 
Team  in  the  Red  Team  game  room.  For  open  games  one  briefing  for  both  teams 
together  will  suffice,  and  it  may  be  conducted  in  either  team’s  game  room  or 
in  the  Control  Team  game  room. 

(5)  Documentation.  The  Chief  Controller  will  provide  copies  of  the 
"Blue  Team  Game  Period  Instruction  for  Team"  form  to  the  Chief,  Blue  Team,  and 
copies  of  the  "Red  Team  Game  Period  Instruction  for  Team"  form  to  the  Chief, 
Red  Team. 

5.  PREPARATION  OF  OPERATION  PLANS  AND  CONCEPTS: 

a.  Introduction.  This  operation  requires  six  steps  to  be  performed  by 
each  player  team  in  accordance  with  the  general  procedures  specified  in 

FM  101-5,^-  with  minor  modifications.  Each  step  is  summarized,  with  no  attempt 
made  to  repeat  detailed  procedures  covered  by  the  field  manual. 

b.  Priority  of  Player  Responsibilities.  Player  Teams  have  two  primary 
responsibilities  related  to  their  military  function  in  the  conduct  of  gaming 
activities.  These  two  responsibilities  may  appear  to  be  in  conflict  at  times, 
but  they  are  stated  here  in  terms  of  their  relative  priorities  in  order  to 
provide  perspective. 

(1)  First  Priority.  The  Player  Team  responsibility  having  first 
priority  is  to  conduct  military  operations  of  assigned  forces  in  a  manner  that 
will  best  support  the  game  objectives. 


1.  FM  101-5,  Staff  Officers’  Field  Manual  -  Staff  Organization  and 
Procedures ,  14  June  1968. 
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(2)  Second  Priority.  The  Player  Team  responsibility  having  second 
priority  is  to  conduct  military  operations  of  assigned  forces  in  a  manner 
that  will  best  reflect  military  staff  and  command  abilities  of  the  players. 

c.  Deduction  of  Mission.  Based  on  the  instructions  provided  to  his  team 

in  the  Controller's  briefing,  supplemented  by  other  previously  issued  documents 
and  instructions,  each  Player  Team  Chief  deduces  his  mission  for  this  game  • 

period.  Through  mission  analysis,  he  determines  the  specified  tasks  to  be 
performed  to  accomplish  the  mission  and  any  implied  tasks  that  he  considers 
appropriate  to  call  to  the  attention  of  his  staff  players. 

d.  Provision  of  Staff  Information.  Based  on  the  deduced  mission,  Player 
Team  members  functioning  as  the  military  staff  provide  to  their  Player  Team 
Chief  available  information  pertinent  to  the  mission. 

e.  Commander's  Guidance.  Based  on  the  information  provided  by  his  staff, 
the  Player  Team  Chief  completes  his  mission  analysis  and  issues  his  planning 
guidance. 

(1)  Planning  guidance  is  the  Player  Team  Chief's  assistance  to  his 
staff  players  in  preparing  or  revising  their  estimates.  The  amount  of  planning 
guidance  varies  with  each  mission,  the  volume  and  validity  of  information 
available,  the  situation,  and  the  experience  of  the  Player  Team  Chief  and  his 
staff  players. 

(2)  Planning  guidance  is  not  limited  to  one  specific  step  in  the 
sequence  of  actions;  however,  initial  guidance  should  precede  the  preparation  . 
of  staff  estimates.  The  Player  Team  Chief  normally  includes  in  his  initial 
guidance  his  restated  mission  as  determined  by  his  mission  analysis;  his 
general  plan  for  using  fire  support  and  nuclear  weapons,  if  appropriate;  any 
other  factors  that  he  considers  important  at  this  time;  and  any  courses  of 
action  that  he  wishes  developed. 

f.  Staff  Estimates: 

3 

(1)  Based  on  the  mission  and  planning  guidance  received,  staff  players^ 
prepare  their  informal  Staff  Estimates  as  required  by  the  military  situation 

and  the  game  objectives. 

(2)  The  informal  Staff  Estimates  themselves  need  not  be  made  into 

written  records;  if  the  situation  dictates  a  written  estimate  for  the  record,  * 

then  a  formal  estimate  should  be  made,  including  essential  portions  of  the 
standard  estimate. 

(3)  Staff  Estimates  result  in  recommendations  as  to  what  actions  the  % 
Player  Team  Chief  should  take  to  accomplish  the  team  mission. 
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g.  Commander's  Estimate  and  Concept: 

(1)  Based  on  the  recommendations  made  by  his  staff  players,  the 
Player  Team  Chief  prepares  his  own  estimate  and  announces  his  Commander's 
Decision  to  his  staff  players.  The  Commander's  Decision  is  recorded. 

(2)  Following  the  decision  statement  (the  last  step  of  the  estimate), 
the  Player  Team  Chief  provides  his  staff  players  with  his  overall  concept  of 
how  the  operation  will  be  conducted  (Commander's  Concept),  which  is  an  ampli¬ 
fication  of  his  decision,  and  explains  any  aspects  he  considers  necessary. 

The  Commander's  Decision,  together  with  the  Commander's  Concept,  provides  the 
basis  for  preparation  of  Paragraph  3a  of  the  operation  order. 

h.  Operation  Orders: 

(1)  Formal  operation  orders  need  to  be  prepared  by  both  Player  Teams 
for  the  start  of  a  game.  These  orders  are  based  on  guidance  provided  by  the 
Game  Director. 

(2)  Subsequent  to  the  first  game  period,  the  term  "operation  order"  is 
synonymous  with  "concept  of  operations;"  as  will  be  seen  in  later  discussions 
each  Player  Team's  concept  is  made  a  matter  of  record  in  the  game  period 
narrative. 

6.  PLAYER  TEAM  BRIEFING  TO  CONTROL  TEAM  AND  GAME  DIRECTOR: 

a.  As  soon  as  Player  Teams  have  completed  their  planning  processes  and 
prepared  a  concept  of  operation,  they  announce  their  readiness  to  brief  those 
plans  and  concepts. 

b.  During  the  early  game  periods,  and  until  game  cycle  operations  become 
stabilized,  it  is  well  that  these  briefings  be  presented  only  to  the  Control 
Team;  however,  as  soon  as  the  operations  do  become  standard,  time  and  effort 
will  be  conserved  if  the  Game  Director  will  attend  the  briefing,  together  with 
any  other  managers  deemed  appropriate. 

c.  The  purpose  of  these  briefings  is  to  provide  the  Game  Director  and  the 
Chief  Controller  with  the  opportunity  to  ensure  that  guidance  of  the  Game 
Period  Concept  is  being  followed;  or,  if  it  is  not,  to  provide  the  Player  Team 
Chief  an  opportunity  to  present  his  rationale  for  deviation. 

d.  When  the  plans  and  concepts  of  both  teams  have  been  approved,  Player 
Teams  immediately  commence  preparation  of  the  gamer  input  orders. 

7.  PREPARATION  OF  UNIT  SCENARIOS: 

a.  The  DIVWAG  Scenario  Language  (DSL)  is  the  source  for  gamer-initiated 
orders  to  units  in  the  DIVWAG  Model.  Appendix  B  to  this  volume  contains  the 
entire  vocabulary  of  that  language.  All  gamers  must  have  a  comprehensive 
understanding  of  the  DSL  in  order  to  run  a  game  efficiently. 
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b.  Although  instructions  for  the  use  of  DSL  are  contained  in  Appendix  B, 
this  paragraph  emphasizes  several  considerations  in  its  use  as  it  relates 
specifically  to  causing  a  simulated  unit  to  perform  some  act  during  a  game 
period . 


(1)  A  simulated  unit  in  the  DIVWAG  Model  will  perform  certain 
functions  without  being  directed  by  a  gamer  to  do  so: 

(a)  In  the  absence  of  orders,  all  units  will  remain  in  place. 

(b)  Artillery  units  will  enter  the  TACFIRE  system  and  respond 
appropriately . 

(c)  Air  defense  units  will  expend  ammunition  against  aircraft. 

(d)  All  units  will  consume  food  and  expend  POL. 

(e)  All  units  will  seek  appropriate  protection  when  attacked  by 
artillery  or  aircraft. 

(f)  All  units  will  operate  available  sensors. 

(g)  All  units  will  receive  resupply  of  consumables,  personnel 
replacements,  and  major  end  items  if  appropriate. 

(h)  Mission  capable  units  will  fly  attack  helicopter  sorties 
and  high-performance  close  air  support  missions  against  appropriate  targets. 

(i)  Engineer  units  will  respond  to  requests  from  other  units  to 
breach  obstacles  or  build  f acil. ties . 

(2)  All  other  activities  must  be  directed  through  use  of  DSL. 

(3)  In  order  for  a  unit  to  respond  to  orders  it  must  have  a  name,  the 
eight-character  alphanumeric  unit  identification  (UID) .  It  must  be  a  resolu¬ 
tion  unit;  i.e.,  it  must  have  people  and  it  must  be  assigned  a  geographical 
location. 

(4)  All  orders  to  a  single  unit  must  be  included  in  a  single  Unit 
Scenario;  i.e.,  in  a  given  game  period  any  one  unit  can  be  given  orders  under 
its  UID  but  a  single  time.  If  the  UID  is  used  for  a  second  set  of  orders  the 
input  deck  will  not  be  compiled. 

c.  Unit  Scenarios  are  prepared  by  Player  Team  members  as  prescribed  by 
the  Player  Team  Chief.  Standard  program  coding  forms  are  used  as  shown  in 
Figure  3-5,  Each  Unit  Scenario  consists  of  three  elements,  assembled  in  the 
order  listed:  a  unit  identification,  a  comment  card,  and  the  list  of  procedure 
statements . 


d.  To  facilitate  review  and  proofing  of  Unit  Scenarios  and  to  facilitate 
keypunching  operations,  a  standard  set  of  indentations  is  recommended  as 
specified  herein.  (Figure  3-5) 

(1)  The  unit  identification  is  preceded  by  the  characters  "ID". 

These  characters  begin  in  column  A  of  the  coding  form. 

(2)  "COMMENT"  cards  begin  in  column  1  of  the  coding  form.  * 

(3)  All  three-character  labels  begin  in  column  3. 

(A)  All  orders  begin  in  column  7. 

8.  PREPARATION  OF  BATTLE  PARAGRAPHS 

a.  Detailed  instructions  on  the  preparation  of  Battle  Paragraphs 

are  included  in  Appendix  B  to  this  volume;  however,  a  brief  discussion  of  pro¬ 
cedures  in  this  paragraph  will  assist  the  gaming  group  to  expedite  preparation. 

b.  At  the  conclusion  of  the  Player  Teams'  briefings  to  control  (Paragraph 
6,  above)  it  is  recommended  that  Control  and  Player  Team  Chiefs  "rough  out" 
the  individual  battles  foreseen  for  the  coming  period.  This  enables  each  team, 
as  well  as  the  Control  Team  to  provide  guidelines  for  contingencies. 

c.  The  Control  Team  is  responsible  for  preparing  the  Battle  Paragraphs 
as  prescribed  in  Appendix  B.  As  stated  therein,  each  battle  must  have  at 
least  one  conditional.  Actually,  most  battles  will  have  more  than  one  such 
conditional  as  the  only  means  to  provide  for  contingencies.  Each  battle  con-  ) 
ditional  muse  have  an  associated  labeled  order  in  the  Unit  Scenario  of  each 
unit  in  the  Battle  Paragraph.  Player  Team  personnel  cannot  prepare  these 
orders  at  thv*  time  they  are  preparing  Unit  Scenarios  because  the  battle  logic 
will  not  have  been  completed;  therefore,  it  is  recommended  that  each  Player 
Team  designate  one  man  to  work  with  the  Control  Team  in  the  preparation  of 
Battle  Paragraphs  and  the  associated  Unit  Scenario  label  orders.  This  should 

be  done  as  early  as  possible  but  no  later  than  completion  of  Unit  Scenarios 
by  the  Player  Teams.  ^ 

9.  COMPUTER  INTERFACE  PROCEDURES: 
a.  Processing  Coding  Forms: 

(1)  When  all  Unit  Scenarios  have  been  coded  onto  standard  program  * 
coding  forms,  they  should  be  reviewed  within  the  Player  Teams  for  obvious 
errors.  When  obvious  errors  are  corrected,  a  copy  should  be  made  and  retained 
and  the  original  forwarded  to  the  Control  Team. 

(2)  Within  the  Control  Team,  the  Blue  and  Red  Controllers  review  the  ' 
coding  forms  and  recommend  disposition  to  the  Chief  Controller.  If  errors 

are  noted  in  logic,  the  recommendation  should  be  to  return  the  forms  to  the 
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Player  Team.  If  there  are  no  obvious  errors  or  if  the  errors  are  minor,  the 
recommendation  to  the  Chief  Controller  should  be  to  send  the  forms  to  the 
keypunch  operator  for  keypunching  and  verifying. 

(3)  The  keypunched  cards  should  be  returned  directly  to  the  originator 
of  the  coding  forms . 

(4)  When  all  keypunching  is  complete,  each  team  assembles  its  card 
deck  and  passes  it  to  the  Control  Team  for  final  assembly.  The  Control  Team 
adds  the  Battle  Paragraphs,  together  with  the  appropriate  data  and  header 
cards  and  prepares  the  assembled  input  deck  for  an  edit. 

b.  Computer  Interface  Processing.  Computer  interface  processing  refers 
to  those  procedures  which  relate  to  actual  computer  operations,  once  the  DSL 
deck  is  assembled  bj  the  Control  Team.  These  processing  procedures  are  ex¬ 
plained  in  detail  in  Appendix  A.  In  brief,  they  include: 

(1)  Preparation  and  assembly  of  the  control  card  deck  for  a  DSL  EDIT 
and  associated  administrative  procedures. 

(2)  Preparation  and  assembly  of  the  control  card  deck  for  a  DSL 
COMPILE  and  associated  administrative  procedures. 

(3)  Preparation  and  assembly  of  the  control  card  deck  for  Operating 
Instruction  processing  and  the  associated  administrative  procedures. 

(4)  Preparation  and  assembly  of  the  control  card  decks  for  processing 
the  game  period  through  the  Period  Processor  and  the  Period  Output  Processor. 

10.  REVIEW  AND  ANALYSIS  OF  GAME  PERIOD  OUTPUT.  At  the  end  of  each  dynamic 
game  cycle  two  types  of  period  output  are  produced;  the  technical  printout 
from  the  Period  Processor,  used  for  diagnostic  purposes  by  the  Model  Mainten¬ 
ance  Team,  and  the  period  reports  from  the  Period  Output  Processor.  Obviously, 
neither  of  these  outputs  is  available  to  initiate  the  first  period;  therefore, 
the  first  Game  Period  Concept  is  prepared  based  upon  guidance  from  the  Game 
Directive,  the  Game  Plan,  and  verbal  guidance  from  the  Game  Director.  Subse¬ 
quent  game  period  turnarounds  commence  with  an  analysis  of  the  output,  each  of 
which  is  discussed  below. 

a.  Technical  Printout: 

(1)  Purpose.  The  primary  purpose  of  the  analysis  of  the  technical 
printout  from  the  Period  Processor  is  to  detect  any  technical  errors  in  the 
operation  of  the  model  programs,  or  any  unsatisfactory  results  of  program 
operations,  and  to  permit  determination  of  the  technical  acceptability  of  the 
results. 
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(2)  Responsibility: 


Ca)  The  Model  Maintenance  Team  is  responsible  for  the  conduct 
of  the  technical  analysis  and  for  the  determination  of  technical  acceptability. 

(b)  The  Analysis  Team  will  conduct  a  subsequent  technical  analysis 
of  this  output  from  the  standpoint  of  technical  acceptability  for  game  results  » 
analysis . 


(c)  The  Control  Team  is  responsible  for  providing  assistance  and 
guidance,  as  requested,  to  both  Model  Maintenance  and  Analysis  Teams. 

(3)  Analysis  Procedures: 

(a)  The  technical  analysis  concerns  three  primary  areas  of 

interest. 

1.  Acceptability  of  time  ranges  (game  time  at  the  end  of  the 
run,  computer  running  time  versus  game  time). 

2.  Legitimacy  of  Period  Processor  termination. 

_3.  Interpretation  of  printed  diagnostic  statements. 

(b)  When  the  analysis  indicates  unacceptable  results,  a  deter¬ 
mination  must  be  made  concerning  necessary  changes. 

I,.  If  errors  stem  directly  from  unsatisfactory  program 
operations,  the  Model  Maintenance  Team  will  determine  the  cause  and  the 
solution  and  report  these  facts  to  the  Chief  Controller  and  the  Game  Director. 

2.  If  errors  stem  from  gamer  input,  either  constant  data 
or  DSL,  the  Model  Maintenance  Team  will  call  on  the  Chief  Controller  to  deter¬ 
mine  corrective  action.  In  turn,  the  Chief  Controller  will  report  the  facts 
to  the  Game  Director. 

(c)  When  the  analysis  indicates  an  acceptable  run,  this  fact  * 
will  be  reported  to  the  Chief  Controller  and  the  Game  Director. 

b.  Period  Output  Reports: 

(1)  Purpose.  Analysis  of  Period  Output  Reports  provides  the  basis 
for  a  decision  regarding  acceptability  of  gaming  procedures  and  the  operational 
acceptability  of  the  results.  See  Appendix  A  for  examples  and  a  discussion  of 
contents  of  the  Period  Output  Reports. 
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(2)  Responsibility: 

(a)  The  Chief  Controller  is  responsible  for  ensuring  that  the 
analysis  is  made  to  determine  operational  acceptability.  Within  the  Control 
Team,  Blue  and  Red  Controllers  will  review  reports  of  their  respective  teams. 
The  Chief  Controller  and  the  Deputy  Chief  Controller  will  spot  check  selected 
portions  of  the  reports  as  specified  by  the  Chief  Controller. 

(b)  Each  Player  Team  Chief  is  responsible  for  ensuring  that  the 
analysis  is  made  to  determine  operational  acceptability. 

(c)  The  Model  Maintenance  and  Analysis  Teams  will  provide  tech¬ 
nical  advice  and  analysis  assistance  as  requested  by  the  Chief  Controller. 

(3)  Analysis  Procedures: 

(a)  Within  the  Control  Team,  the  emphasis  of  the  analysis  it  to 

determine: 

1.  Was  the  concept  of  operation  implemented  acceptably? 

2.  What  is  the  status  of  mission-essential  equipment? 

_3.  Have  units  reached  a  termination  criterion? 

4^  What  are  units'  loss  rates? 

_5.  What  significant  conditionals  were  met  during  the  period 
.6.  Were  the  game  period  objectives  attained? 

]_.  What  is  the  overall  acceptability  of  the  game  period? 

(b)  Each  Player  Team's  in-depth  analysis  is  made  to  determine: 

Was  the  concept  of  operation  Implemented  acceptably? 

2,-  What  is  the  status  of  mission-essential  equipment? 

_3.  Have  units  reached  a  termination  criterion? 

.4.  What  is  the  status  of  supply  actions? 

_5.  What  are  the  loss  rates  of  significant  units  in  the 

force? 

.6.  What  is  the  tactical  integrity  of  the  force? 

]_.  What  is  the  overall  acceptability  of  the  game  period? 
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(c)  When  the  analysis  indicates  unacceptable  results,  a  deter¬ 
mination  must  be  made  as  to  the  remedial  actions.  The  Chief  Controller  will 
consult  with  Model  Maintenance  and  Analysis  Teams  to  arrive  at  the  preferred 
course  of  action.  This  course  of  action  will  be  presented  to  the  Game  Direc¬ 
tor  for  approval,  necessary  changes  will  be  made,  and  the  necessary  corrective 
action  taken. 


(d)  When  the  analysis  indicates  the  results  are  operationally 
acceptable,  the  Game  Director  will  be  so  advised,  and  approval  to  initiate 
game  period  turnaround  will  be  requested. 

c.  Error  Correction: 

(1)  Irrespective  of  the  error  type,  except  for  DPFO  errors,  the 
corrective  action  should  be  a  coordinated  process  among  Model  Maintenance, 
Analysis,  and  Control  Teams.  This  coordination  is  necessary  to  ensure  that 
each  team  understands  the  impact  of  the  correction  on  game  operations. 

(2)  In  general,  errors  fall  into  two  categories,  operational  and 
technical. 


(a)  Operational  errors  may  be  due  to  faulty  composition  of  Unit 
Scenarios  or  Battle  Paragraphs,  exceeding  some  limiting  constraint  of  the  model; 
or  inadequate,  inaccurate,  or  inconsistent  constant  data  input  entries. 

(b)  Technical  errors  may  be  due  to  faulty  model  logic  or  technical 

rules. 


(c)  The  Control  Team,  in  coordination  with  Model  Maintenance  and 
Analysis  Teams,  is  responsible  for  the  correction  of  DSL  errors.  Other  opera¬ 
tional  errors  should  be  corrected  as  a  coordinated  effort  between  the  Control 
Team  and  the  Model  Maintenance  Team  with  liaison  to  the  Analysis  Team. 

(d)  The  Model  Maintenance  Team,  in  coordination  with  Analysis  and 
Control  Teams,  is  responsible  for  the  correction  of  technical  errors.  The 
Model  Maintenance  Team  is  also  responsible  for  coordination  with  the  DPFO  in 
case  of  DPFO  errors. 

11.  MAINTENANCE  OF  GAME  RECORDS: 

a.  Game  records  consist  of  the  following  items,  each  of  which  is  dis¬ 
cussed  further  in  Appendix  A  to  this  volume: 

.  Game  Period  Concept 
.  Compile  of  Gamer  Orders 
.  Game  Period  Reports 
.  Graphics 

.  Game  Period  Narratives 


3-26 


3 


b.  The  Game  Period  Narratives  are  as  important  to  the  documentation  of 
a  war  game  as  are  the  Game  Period  Concepts.  They  should  be  concise,  vivid 
descriptions  of  significant  events  of  a  game  period,  and  they  should  be  indic¬ 
ative  of  the  extent  to  which  game  period  objectives  were  achieved,  as  embodied 
in  the  Game  Period  Concept.  Figure  3-6  contains  an  outline  of  a  Game  Period 
Narrative  format  which  is  considered  appropriate  for  most  DIVWAG  applications. 
Instructions  as  to  timing  its  preparation  are  included  in  Appendix  A  to  this 
volume. 


GAME  PERIOD  NARRATIVE 


Section  I.  IDENTIFICATION 


1.  GAME.  _ — _ _ 

2.  DYNAMIC  GAME  PERIOD  REPORTED _ 

3.  GAME  TIME  COVERED.  From _ -to 


Section  II.  SUMMARY  OF  PERIOD 


4.  SITUATION  AT  END  OF  PERIOD.  (Control  Team  prepares  after  review  of 
Player  Teams'  reports.)  Refer  to  any  appendages,  such  as  situation 
graphics.  Cover  any  particularly  significant  aspects  of  the  situation. 


5.  OPERATIONS  DURING  PERIOD: 
a.  Blue: 

(1)  Combat.  Under  a  separate  lettered  subparagraph,  provide  a 
brief  narrative  resume  of  the  combat  actions  and  any  other  significant 
events  of  each  brigade  and  the  separate  combat  units,  if  any.  This  nar¬ 
rative  should  read  much  the  same  as  an  after  action  report  covering  the 
brigades  or  separate  combat  elements,  as  differentiated  from  separate 
battle  reports  on  each  subelement,  by  battle  name. 


Figure  3-6.  Game  Period  Narrative  Outline  (continued  on  next  page) 
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(2)  Combat  Support.  A  separate  subparagraph  should  be  used  to 
summarize  each  type  combat  support  activity  to  be  reported;  e.g., 

(a)  Artillery 

(b)  Attack  Helicopter 

(c)  Air  Force  CAS 

(d)  Engineer 

(e)  Etc. 

(3)  Combat  Service  Support.  A  separate  subparagraph  should  be 
used  to  summarize  each  combat  service  support  activity  to  be  reported. 

b.  Red.  Red  subparagraphing  should  follow  the  same  sequence  and 
the  same  philosophy  as  Blue. 


6.  OPERATIONAL  FACTORS  INFLUENCING  GAME  RESULTS.  Cover  that  pertinent 
information  not  appropriately  covered  in  preceding  paragraphs;  e.g., 
weather,  terrain,  and  visibility. 


7.  ANALYSIS  OF  OPERATIONS  DURING  THE  PERIOD: 

a.  Blue.  Present  a  brief  analysis  of  the  operations  by  Blue  as  a 
force.  Include  significant  accomplishments  and/or  failures. 

b.  Red.  Present  a  brief  analysis  of  the  operations  by  Red.  Address 
division  level  forces.  Include  significant  accomplishments  and/or 
failures. 

c.  Analyze  achievement  of  game  period  objectives. 


8.  SYSTEM  CONSIDERATIONS  AFFECTING  GAME  RESULTS.  (Prepared  by  Chief 
Controller . ) 

a.  Present  conclusions  concerning  anomalies  caused  by  constant  data 
and  gamer  orders  input. 


Figure  3-6.  Game  Period  Narrative  Outline  (continued) 


b.  Present  recommendations  for  system  modification  which  would 
improve  game  results. 

c.  Present  recommendations  for  side  analyses /sensitivity  tests. 


Section  III.  PLANS  FOR  NEXT  PERIOD 

9.  CONCEPT  OF  OPERATION: 

a.  Blue.  A  concise  statement  of  the  concept  as  presented  to  Control 
Team  at  the  briefing. 

b.  Red.  Same  as  9a  above. 

10.  FORCE  MISSIONS: 

a.  Blue.  Control  Team  prepares  after  receipt  of  Paragraph  9a  from 
Blue. 

b.  Red.  Control  Team  prepares  after  receipt  of  Paragraph  9b  from 

Red. 

11.  PLANS  FOR  THE  PERIOD.  The  same  sequencing  and  philosophy  is  used  in 
structuring  this  paragraph  as  was  used  in  structuring  Paragraph  5. 

a.  Blue.  Summarize  operations  planned.  Include  any  deviations  from 
original  concepts  or  from  doctrine. 

(1)  Combat  Elements 

(2)  Combat  Support  Elements 

(3)  Combat  Service  Support  Elements 

b.  Red.  Same  as  for  Blue. 


Figure  3-6.  Game  Period  Narrative  Outline  (concluded) 
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APPENDIX  A 


GAME  PERIOD  CYCLE  OPERATIONS 


1.  INTRODUCTION.  This  appendix  contains  amplifying  discussions  on  operations 
and  procedures  presented  in  Chapter  3,  Dynamic  Game  Play,  of  this  volume. 
Specifically,  the  detailed  administrative  procedures  associated  with  computer 
interface  are  covered  herein  as  are  descriptions  of  period  reports  and  the 
analysis  thereof. 

2.  COMPUTER  INTERFACE  PROCEDURES: 

a.  Stages  of  Processing.  There  are  four  separate  and  sequential  stages 

in  DIVWAG  computer  processing;  DSL  EDIT,  DSL  COMPILE  (Orders  Input  Processing) , 
Operating  Instructions  Load,  and  Period  Processing.  Although  each  stage  may 
be  considered  separate,  the  general  procedures  for  all  are  similar.  They  differ 
in  detail  of  control  card  decks  and  work  request  forms,  and  each  stage  is 
discussed  in  depth  in  the  subparagraphs  that  follow. 

b.  DSL  EDIT: 

(1)  General.  The  primary  function  of  the  EDIT  process  is  to  identify 
the  existence  and,  insofar  as  possible,  the  nature  of  errors  in  the  DIVWAG 
Scenario  Language  (DSL)  deck.  While  the  gaming  staff  must  prescribe  and 
employ  quality  control  measures  in  deck  preparation  and  assembly,  there  is  a 
point  beyond  which  manual  measures  are  economically  unsound.  For  example,  two 
members  of  each  gaming  element  (Blue  Team,  Red  Team,  and  Control  Team)  could 
spend  over  an  hour  checking  punched  cards  to  ensure  an  error-free  deck,  but 
the  EDIT  process  for  the  assembled  deck  may  require  but  2  to  3  minutes  of 
computer  time.  When  the  order  deck  has  gone  through  the  EDIT  process  errors 
are  flagged,  and  a  legible  listing  of  the  input  is  produced;  therefore,  it  is 
suggested  that  liberal  use  be  made  of  this  capability  as  a  means  to  speed  game 
period  turnaround. 

(2)  Processing  Procedures : 

(a)  General.  The  Control  Team  Programmer,  under  the  supervision 
of  the  Chief  Controller,  processes  the  DSL  decks.  The  assembled  deck  is  passed 
to  the  Control  Team  Programmer  after  the  Chief  Controller  has  added  the  DSL 
control  cards  (see  Appendix  B  to  this  volume).  The  Control  Team  Programmer 
integrates  the  EDIT  control  deck.  See  Figure  A-l.  It  is  not  necessary  or 
recommended  to  reload  the  data  file  if  it  already  contains  the  data  to  be  used 
unless  the  run  immediately  preceding  this  was  a  Period  Report  run.  The 
omission  of  that  step  saves  time  and  also  prevents  the  possibility  of  loading 
the  file  with  the  incorrect  tape.  The  data  file  must  be  reloaded  after  a 
Period  Report  run. 

(b)  Work  Request.  A  work  request  form  is  prepared.  See 

Figure  A-2. 
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ATTACH(DSLB1N  tDSLBIM ,  IIHXXmZ.MR-l ) 
S RETURN (UTILLD)  '  " 

UNLOAD (TAPE 2 1 ) 


J  ATTACH (UTILLD, UtlLLOAD , ID-XXXXX.KA- 1 ) 

tBEL(TAPE2 ] ,R,L-DIVWA CREST, D-PE.VSN-XXXX) 
JEST(TAPE1  ,PK,DWTWQ) 

0»  (TAPED  _ 

REHQVE(TAPEl.PWIVO) 

Repack,  dwiwo,e. 

"LOADER (PP LOADER)  | 


f OMIT  WHEN 
DISK  PILE 
-  IS  PREVIOUSLY 
LOADED  WITH 
PROPER  DATA 


^  TASK,TN*XXXXXX,TA«XXXXX,WP-XXtOS-XX,TR-n 
*»"  ' 

DSL,QU05000,T500,NT1.  NAME  EXT 


Figure  A-l.  DSL  EDIT  Deck  Assembly 
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Figure  A-2.  Sample  Work  Request  Form  for  DSL  EDIT 
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Programmer. 


1. 

Item 

1. 

Enter 

code  name  assigned  to  the  gaming  project. 

2. 

Item 

2. 

Enter 

computer  core  requirements  for  this  job. 

3. 

Item 

3. 

Enter 

DSL. 

4. 

I  tem 

4. 

Enter 

last  name  of  Control  Team  Programmer. 

5. 

Item 

5. 

Enter 

telephone  extension  of  Control  Team 

6. 

I  tem 

6. 

Enter 

estimate  of  machine  time  required. 

2- 

Items 

i  7, 

9,  and  10.  Leave  blank. 

8. 

Item 

8. 

Enter 

U  for  unclassified. 

9. 

Item 

11. 

Enter  X  in  production  box. 

10.  Items  12  through  18.  Consult  with  the  Model  Maintenance 
Team  for  the  correct  disk  pack  entry  for  the  first  row  of  column  12.  If  the 
data  file  is  to  be  reloaded,  the  reel  number  and  label  of  the  appropriate  dump 
tape  are  entered  on  the  second  row;  otherwise,  the  remaining  rows  are  left 
blank. 


11.  Items  19  through  24,  and  26.  Leave  blank. 

12.  Item  25.  Enter  special  instructions  such  as  notification 
of  completion  and  relationship  to  other  runs. 

(c)  Logging  Out  of  Deck.  In  the  Log  Journal  the  Control  Team 
Programmer  enters  information  from  items  1  and  3  of  the  work  request  form  and 
in  the  out  column,  enters  the  date  and  time  out. 

(d)  Transportation  of  Deck  to  ADP  Facility.  The  messenger 
transports  the  items  to  the  ADP  Facility,  using  transportation  he  summoned  at 
the  time  he  was  alerted,  and  delivers  the  items  to  the  DPFO  Job  Control 
Point.  He  then  returns  to  the  War  Game  Facility. 

(e)  DPFO.  At  this  point,  the  DPFO  assumes  responsibility 
for  logging  the  job  into  the  facility,  establishing  a  priority  for  the 

job,  entering  the  job  onto  the  machine,  executing  the  job,  and  notifying  the 
Control  Team  Programmer  that  the  job  is  completed. 

(f)  Transportation  of  Deck  to  War  Game  Facility.  Upon  notifica¬ 
tion  that  the  job  has  been  completed,  the  messenger  summons  transportation 
and  proceeds  to  the  DPFO  Job  Control  Point.  There  he: 

_1.  Checks  the  job  to  see  that  the  work  request  form,  the  DSL 
EDIT  deck,  and  the  printout  all  correspond,  and  that  no  materials  from  other 
jobs  have  been  included  inadvertently. 


2.  Signs  for  the  completed  job  by  initialing  the  original 
copy  of  the  work  request  form,  which  he  leaves  at  the  DPFO. 

_3.  Transports  the  DSL  EDIT  deck,  the  printout,  and  the 
duplicate  copy  of  the  work  request  form  to  the  War  Game  Facility  and  delivers 
all  items  to  the  Control  Team  Programmer. 

(g)  Logging  In  of  Deck.  In  the  Log  Journal,  the  Control  Team 
Programmer  finds  the  previous  Logging  Out  entry  for  this  job,  and  in  the  In 
Column  enters  the  date  and  time  in. 

(h)  Removal  of  Control  Deck.  The  Control  Team  Programmer 
separates  the  DSL  deck  from  the  EDIT  control  deck;  secures  the  DSL  deck;  and 
consolidates,  secures,  and  stores  the  EDIT  control  deck. 

(i)  Filing  of  Work  Request  Form.  The  Control  Team  Programmer 
then  files  the  work  request  form  in  his  file  of  completed  work  request  forms. 

(j)  Delivery  of  DSL  Deck  and  EDIT  Printout.  The  Control  Team 
Programmer  delivers  the  DSL  deck  and  the  EDIT  printout  to  the  Records  Con¬ 
troller  of  the  Control  Team.  This  completes  the  processing  of  the  data 
through  EDIT. 

(3)  Error  Analysis  and  Correction: 

(a)  The  Chief  Controller  is  responsible  for  the  analysis, 
revision,  and  reassembly  of  the  deck.  He  will  call  upon  the  Model  Maintenance 
Team  for  any  required  assistance  in  analyzing  the  battle  paragraphs. 

(b)  DSL  EDIT  processing  provides  error  diagnostics  to  the  analyst 
in  the  form  of  diagnostic  remarks  on  the  printout.  The  diagnostic  statements 
are  specific  and  pinpoint  the  error  directly.  Errors  are  Identified  as  either 
fatal  or  warning. 


,1.  Fatal  Errors.  An  error  indicated  as  fatal  would  always 
cause  incorrect  results  and  must  be  corrected  before  a  successful  DSL  COMPILE 
can  be  completed. 


2.  Warning  Errors.  An  error  condition  identified  as  a 
warning  is  likely  to  cause  incorrect  results.  A  thorough  analysis  of  the 
technique  used  should  be  made  to  insure  that  the  desired  result  will  be 
achieved . 

(c)  Minor  errors  are  corrected  by  entering  directly  on  the 
punched  card  the  number  of  the  column  in  which  the  error  correction  begins, 
followed  by  a  slash(/),  followed  by  the  correct  entry.  If  the  correction 
includes  blank  columns,  such  are  indicated  either  by  a  carat  (^)  or  Ly  a 
bar  b  (b).  Within  each  gaming  group,  a  single  convention  should  be  adopted 
so  as  not  to  confuse  the  keypunch  operator.  The  indicated  correction  must  be 
located  on  the  faulty  card  so  that  the  keypunch  operator  can  read  it  while 
the  faulty  card  is  in  the  duplicating  section  of  the  machine. 
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(d)  Extensive  errors  on  a  single  card  should  be  corrected  by 
preparing  the  correct  data  on  a  standard  coding  form  and  punching  a  new  card. 

(e)  When  all  errors  are  corrected  and  the  deck,  reassembled,  the 
Chief  Controller  decides  if  a  new  EDIT  is  desirable  or  if  the  deck  can  go 
directly  to  COMPILE.  If  a  new  EDIT  is  necessary  the  procedures  are  repeated; 
if  not  necessary,  the  following  procedures  are  initiated  for  a  COMPILE. 

c.  DSL  COMPILE: 

(1)  A  DSL  COMPILE  processes  the  DSL  deck  through  the  Orders  Input 
Processor.  The  primary  function  of  this  processor  is  to  translate  the  DIVWAG 
Source  Language  (DSL)  into  computer  language  that  the  DIWAG  Model  understands.  ' 
In  so  doing,  the  processor  dumps  a  printout  of  all  cards  in  the  deck  which 
permits  a  final  check  on  both  constructive  and  logic  errors  prior  to  processing 
the  data  through  the  Period  Processor. 

(2)  Responsibilities  and  procedures  for  the  DSL  COMPILE  are  similar 
to  those  of  the  EDIT,  except  as  follows: 

(a)  The  EDIT  control  deck  is  replaced  by  the  Orders  Input  control 
deck.  Figure  A-3.  Note  chat  the  DSL  COMPILE  deck  differs  in  that  it  creates  a 
dump  tape  which  may  be  used  to  reload  the  data  file. 


(b)  The  work  request  form  is  filled  out  as  shown  in  Figure  A-4. 
Entries  are  self-explanatory  except  for  Items  12  through  18.  These  entries 
are  crucial  and  emphasize  the  criticality  of  meticulous  records-keeping  pro¬ 
cedures.  To  complete  these  blocks,  the  Control  Team  Programmer  consults  with 
the  Model  Maintenance  Team  for  the  disk  pack  number  to  be  placed  in  the  first  ■' 
row  of  column  12.  If  the  data  file  must  be  reloaded,  the  Control  Team 
Programmer  checks  his  file  for  the  tape  number  of  the  previous  period  dump 
tape.  This  step  is  crucial.  If  an  incorrect  dump  tape  number  is  used,  the 
program  will  execute,  and  the  discontinuity  will  not  be  evident  without  a 
detailed  technical  review.  The  dump  tape  number  is  inserted  in  the  second 
row  of  column  12,  and  its  label  is  entered  in  the  second  row  of  column  18. 

The  Control  Team  Programmer  completes  the  third  row  of  columns  13,  14,  15,  andv» 

16  as  shown  in  Figure  A-4.  On  the  third  row  of  column  17  place  the  Julian 

retention  date  of  the  start  of  period  tape  that  will  be  created  by  the  Orders 

Input  Processor.  On  the  third  row  of  column  18  enter  the  label  desired  for  the 

start  of  period  tape.  This  label  is  affixed  to  the  physical  reel  of  tape  and, 
along  with  its  reel  number,  is  the  identification  means  for  the  output  of  this 
phase  of  the  computer  processing. 

(3)  When  the  finished  job  is  returned  to  the  facility,  logged,  and 
administratively  processed  as  was  the  EDIT  Job,  the  DSL  deck  and  the  COMPILE 
printout  are  delivered  to  the  Chief  Controller  for  error  analysis  and  correction. 

(4)  Error  analysis  and  correction  proceed  as  follows. 


Figure  A-3.  DSL  COMPILE  Orders  Input  Processor 
Deck  Assembly 
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(a)  The  DSL  COMPILE  detects  the  same  type  errors  as  detected  by 
EDIT.  It  detects  errors  in  logical  structure  which,  if  not  corrected,  either 
would  not  be  processed  by  the  Period  Processor  or  would  result  in  an 
unexpected  event  which  could  cause  unacceptable  game  period  results. 

(b)  Error  correction  procedures  are  the  same  as  prescribed  for  the 
DSL  EDIT  except  that  the  COMPILE  must  be  rerun  if  any  errors  are  found.  The 
same  processing  procedures  are  used  for  a  rerun  as  for  the  initial  run.  If 
there  are  no  errors,  the  next  step  is  to  load  the  Operating  Instructions  if 
required  or  proceed  to  the  Period  Processor. 

d.  Operating  Instructions  Loader.  The  Operating  Instructions  composes 
the  last  general  category  of  input  orders  recognized  by  the  Period  Processor. 

The  purpose  of  the  Operating  Instructions  is  to  provide  orders  to  the  Period 
Processor  in  the  use  of  sensors,  basic  decision  factors  for  the  application  of 
fire  support,  allocation  of  Air  Force  close  air  sorties,  and  introduction  of 
battlefield  intelligence  from  other  battlefield  sources.  Operating  Instruc¬ 
tions  must  be  prepared  for  the  initial  period  of  a  game  and  may  be  prepared  at 
the  beginning  of  any  succeeding  game  period.  If  Operating  Instructions  are 
not  provided  between  game  periods,  the  set  of  instructions  from  the  previous 
period  is  maintained. 

(1)  Responsibility.  The  Control  Team  Programmer  is  responsible  for 
processing  the  Operating  Instructions  deck, 

(2)  General  Procedures.  Processing  of  the  deck  starts  with  the 
preparation  of  the  control  deck  and  ends  with  delivery  of  the  computer  printout. 
It  is  not  necessary  or  recommended  Co  reload  the  data  file  if  it  already 
contains  the  data  to  be  used  unless  this  run  immediately  follows  a  Period 
Report  run.  The  omission  of  that  step  saves  time  and  also  prevents  the 
possibility  of  loading  the  file  with  the  incorrect  tape.  The  data  file  must 

be  reloaded  after  a  Period  Report  run. 

(3)  Preparation  of  Operating  Instructions  Loader  Control  Deck. 

(a)  The  source  deck  for  the  Operating  Instructions  is  prepared 
in  accordance  with  the  guidance  contained  in  Appendix  C.  In  addition  the  data 
file  created  by  the  DSL  COMPILE  (Orders  Input  Processor)  is  input  to  this  task. 
An  acceptable  DSL  COMPILE  should  be  accomplished  before  the  processing  of  the 
Operating  Instructions  deck. 

(b)  The  control  deck  assembly  consists  of  the  cards  shown  in 

Figure  A-5. 

(4)  Preparation  of  Work  Request  Form.  The  Control  Team  Programmer 
alerts  the  messenger  that  a  transport  mission  is  imminent  and  then  prepares 
two  copies  of  the  work  request  form  as  shown  in  Figure  A-6,  and  as  follows: 


(a)  Item  1.  Enters  code  name  assigned  to  the  project. 
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Figure  A-5.  Operating  Instructions  Deck  Assembly 
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(b)  Item  2.  Enters  computer  core  requirements  for  this  job. 

(c)  Item  3.  Enters  OPRNS. 

(d)  Item  4.  Enters  last  name  of  Control  Team  Programmer. 

(e)  Item  5.  Enters  telephone  extension  of  Control  Team  Programmer 

(f)  Item  6.  Enters  estimate  of  machine  time  required. 

(g)  Items  7,  9,  and  10.  Leaves  blank. 

(h)  Item  8.  Enters  U  for  unclassified. 

(i)  Item  11.  Enters  X  in  production  box. 

(j)  Items  12  through  18.  Consults  with  the  Model  Maintenance 

Team  for  the  disk  pack  number  to  be  placed  in  the  first  row  of  column  12.  If 
the  data  file  must  be  reloaded  the  Control  Team  Programmer  checks  his  file  for 
the  tape  number  of  the  DSL  COMPILE  dump  tape.  This  step  is  crucial.  If  an 
incorrect  dump  tape  number  is  used  the  program  will  execute,  and  the  discontin¬ 
uity  will  not  be  evident  without  a  detailed  technical  review.  The  dump  tape 
number  is  inserted  in  the  second  row  of  column  12,  and  its  label  is  entered  in 
the  second  row  of  column  18.  The  Control  Team  Programmer  completes  the  third 

row  of  columns  13,  14,  15,  and  16  as  shown  in  Figure  A-6.  On  the  fifth  row  of 

column  17  place  the  Julian  retention  date  of  the  output  tape  that  will  be 
created  by  the  Operating  Instructions  Processor.  On  the  third  row  of  column 

18  enter  the  label  desired  for  the  start  of  period  tape.  This  label  is  affixeu 
to  the  physical  reel  of  tape  and,  along  with  its  reel  number,  is  the  identi¬ 
fication  means  for  the  output  of  this  phase  of  the  computer  processing. 

(k)  Items  19  through  24,  and  26.  Leaves  blank. 

(l)  Item  25.  Enters  special  instructions  such  as  notification  of 

completion  and  relationship  with  other  runs. 

(5)  Logging  Out  of  Deck.  In  the  Log  Journal  the  Control  Team  Pro¬ 
grammer  enters  information  from  items  1  and  3  of  the  work  request  form  and, 
in  the  Out  column,  enters  the  date  and  time  out. 

(6)  Transportation  of  Deck  to  the  DPFO.  The  Control  Team  Programmer 
delivers  to  the  messenger  the  deck  and  both  copies  of  the  prepare j  work 
request  form.  The  messenger  transports  the  items  to  the  DPFO,  using  trans¬ 
portation  he  summoned  at  the  time  he  was  alerted,  and  delivers  the  items  to  the 
DPFO  Job  Control  Point.  He  then  returns  to  the  War  Game  Facility. 

(7)  Operating  Instructions  Processing.  At  this  point  the  DPFO 
assumes  responsibility  for  logging  the  job  into  the  facility,  establishing  a 
priority  for  the  job,  entering  the  job  onto  the  machine,  executing  the  job 
and  notifying  the  Control  Team  Programmer  that  the  job  is  completed. 


(8)  Transportation  of  Deck  to  War  Game  Facility.  Upon  notification 
that  the  job  has  been  completed,  the  Control  Team  Programmer  instructs  the 
messenger  to  pick  up  the  job.  The  messenger  summons  transportation  and  pro¬ 
ceeds  to  the  DPFO  Job  Control  Point,  where  he: 

(a)  Checks  the  job  to  see  that  the  work  request  form,  the  input 
deck,  and  the  printout  all  correspond,  and  that  no  materials  from  other  jobs 
have  been  included  inadvertently. 

(b)  Signs  for  the  completed  job  by  initialing  the  original  copy 
of  the  work  request  form,  which  he  leaves  at  the  DPFO. 

(c)  Transports  the  decks,  the  printout,  and  the  duplicate  copy 
of  the  work  request  form  to  the  War  Game  Facility  and  delivers  all  items  to 
the  Control  Team  Programmer. 

(9)  Logging  In  of  Deck.  In  the  Log  Journal,  the  Control  Team  Pro¬ 
grammer  finds  the  previous  Logging  Out  entry  for  this  job  and  in  the  In  column 
enters  the  date  and  time  in. 

(10)  Removal  of  Control  Deck.  The  Control  Team  Programmer  separates 
the  Operating  Instructions  deck  from  the  control  deck;  secures  the  Operating 
Instructions  deck;  and  consolidates,  secures,  and  stores  the  control  deck. 

(11)  Filing  of  Work  Request  Form.  The  Control  Team  Programmer  files 
the  work  request  form  in  his  file  of  completed  work  request  forms. 

(12)  Delivery  of  the  Operating  Instructions  Deck  and  the  Printout. 

The  Control  Team  Programmer  delivers  the  Operating  Instructions  deck  and  the 
printout  to  the  Records  Controller  of  the  Control  Team.  This  completes  the 
processing  of  the  data  through  the  Operating  Instructions  Processor. 

e.  Period  Processor.  In  general,  most  procedures  and  functional  steps 
for  the  Period  Processor  are  similar  to  or  identical  to  those  for  processing 
data  through  the  previous  steps,  with  a  few  major  exceptions  or  changes.  To 
preclude  any  ambiguity,  each  item  is  listed  below  with  an  indication  of  any 
changes  applicable  for  the  Period  Processor. 

(1)  Responsibility.  The  Control  Team  Programmer  is  responsible  for 
processing  the  period. 

(2)  General  Procedure.  Processing  of  data  through  the  Period  Pro¬ 
cessor  starts  with  the  preparation  of  control  decks  and  ends  with  delivery 
of  game  period  reports  and  printout. 

(3)  Run  Sequence  Technique. 

(a)  The  recommended  procedure  is  to  utilize  the  SCOPE  dependency 
queue  feature  as  illustrated  in  the  following  examples.  This  permits  all 
Period  Processor  decks  and  the  Period  Output  Processor  deck  to  be  input  at 
once  and  they  will  be  processed  in  the  demised  order.  When  the  TRANF  card 


is  encountered  in  each  job,  the  next  job  will  be  permitted  to  execute.  Refer 
to  the  Control  Data  Corporation  SCOPE  Reference  Manual  for  a  complete 
explanation  of  this  feature. 

(b)  If  all  decks  are  prepared  properly  and  executed  sequentially, 
the  data  file  should  not  be  reloaded  at  the  beginning  of  each  job  for  three 
reasons . 


1_.  The  data  file  already  contains  the  correct  data  and  the 
time  required  to  reload  it — approximately  20  minutes — is  wasted. 

2^  The  reel  number  of  the  dump  tape  to  be  used  is  not  known 
when  the  run  is  submitted. 

,3.  A  greater  risk  of  loading  the  data  file  from  the  wrong 
tape  is  introduced.  Therefore,  the  utility  load  control  cards  (identified  by 
brackets  in  the  figures)  should  be  omitted  from  the  decks  when  a  continuous 
job  sequence  is  submitted  and  the  identification  of  TAPE21  should  be  omitted 
from  the  associated  work  requests.  The  utility  load  operation  is  necessary 
for  a  Period  Processor  restart  following  an  abnormal  termination  and 
recommended  for  the  first  job  in  a  series. 

NOTE:  The  data  file  must  be  reloaded  once  after  the  Period  Output  Processor 
run  prior  to  any  other  run. 

(A)  Preparation  of  Period  Processor  Control  Decks: 

(a)  In  contrast  with  the  previous  processes,  there  is  no  source 
deck  for  the  Period  Processor.  Instead,  the  source  input  for  the  Processor  is 
the  execute  program  tape  produced  during  either  the  Orders  Input  Processing  or 
the  loading  of  Operating  Instructions.  This  execute  program  tape  must  be 
acceptable  before  period  processing  can  be  started. 

(b)  When  the  volume  of  input  data  is  large,  computer  time 
limitations  may  require  breaking  the  game  period  into  increments  for  process¬ 
ing.  The  first  processing  increment  is  called  the  Start  of  Period,  and  all 
subsequent  increments  are  called  Period  Restart.  All  increments  are  numbered 
consecutively  inasmuch  as  the  output  dump  tape  from  each  increment  functions 
as  the  input  source  tape  for  the  next  increment. 

(c)  The  number  of  increments  required  depends  on  the  volume  of 
data  processed  and  priorities  at  the  DPFO.  Usually,  preparations  are  made  for 
at  least  three  increments.  Each  increment  requires  a  separate  control  deck 
and  run  request  form. 

(d)  The  control  deck  assembly  for  the  Start  of  Period  is 
illustrated  in  Figure  A-7.  Only  the  data  card  varies.  The  data  card  contains 
four  types  of  information: 

.  Run  identification 
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Figure  A-7.  Period  Processor  Start  of  Period  Deck 
Assembly 
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.  Run  time  in  minutes 


.  Restart  time  in  minutes 
.  Optional  print  switches. 

The  data  card  is  prepared  by  the  Control  Team  Programmer  after  coordination  wit)4 


the  Control  and  Model  Maintenance  Teams.  The  print  switches  which  produce  tech¬ 
nical  printout  in  the  Period  Processor  Output  will  be  turned  off  (i.e.  ,  entered 
as  zero)  unless  the  Model  Maintenance  Team  requests  any  or  all  of  the  four 
switches  turned  on  (i.e.,  set  to  one).  Start  of  Period  data  card  entries  are 
as  follows : 

Start  of 

Period  Card 

Beginning 
Card  Column 

End ing 

Card  Column 

Number  of 
Characters 

Data  Element 
Description 

1 

4 

4 

Run  identification  code  * 

may  be  any  four  nonblank 
characters  except  "REST" 

11 

15 

5 

Computer  running  time 
cutoff  in  wall  clock 
minutes 

16 

20 

5 

Restart  dump  interval  in  ' 
wall  clock  minutes 

21 

24 

4 

Optional  print  switches 

(e)  The  control  deck  assembly  for  Period  Restart  is  illustrated 
in  Figure  A-8.  Only  the  restart  data  card  varies.  The  restart  data  card 
content  and  its  preparation  are  identical  to  those  for  the  data  card  in  the 

Start  of  Period  deck,  except  the  card  entry  starts  with  restart.  Restart  data 
card  entries  are  as  follows: 

Restart  Period  Card 

Beginning 
Card  Column 

Ending 
Card  Column 

Number  of 
Characters 

Data  Element 
Description 

1 

4 

4 

Enter  "REST" 

11 

15 

5 

Computer  running  time 
cutoff  in  wall  clock 
minutes 

A-16 


3 


END- OF- PILE  CAW) 

^ . 

restart  data  card 


END-OF-RECORD  CARD 


TRANSP (CREPT) 


JATTACN(BIN>DIVWACBIN,ID«X30g0CX,MR"l) 
REWIND (TAPE I) 

QUEST. TAPEAl ,LP. _ 

EL  (TAPE40 ,  W .  L-BISTDRY ,  X-SV ,  \>?Z ,  T-60) 
L(TAPE41,W,L-DIVWACREST,X-SV,D-PE,T-60)  - 
RETVJRN(UTILLD>  ~ 

'uNUAD(TAPE21)  —  | 


J ATTACH  (  UT ILLD ,  UTILUAD ,  ID- TOW  ,MR-1 ) 
EQUEST,TAPE1,PK,DWTW0. 
8EL(TAPE21,R,L»DIVWACRtST,VSH"mX,tNPE) 

URN (TAP El) _ 

E.TAPEl.DWTVf .  ■■  ■  ■■ 

Repack,  dvwivD.e. 

'l4ADER(PPUADR)  | 


OMIT  WHEN 
DISK  PILE 
-IS  PREVIOUSLY 
LOADED  WITH 
PROPER  DATA 


TASK, TN-XIXXXX ,TA-XXXXX,tfP-XX  ,<S-XXXXXX ,TR-XX 
DVR1B.CM124000,T20000,NT2,DDV12. NAME  EXT I 


Figure  A-8.  Period  Processor  Restart  Deck  Assembly 
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Beginning 

Ending 

Number  of 

Data  Element 

Card  Column 

Card  Column 

Characters 

Description 

16 

20 

5 

Restart  dump  interval  ii 
wall  clock  minutes 

21 

24 

4 

Optional  print  switches 

(f)  All  control  decks  for  all  period  restarts  are  identical, 
except  the  first  card  and  the  TRANSF  card  hence  the  additional  decks  required 
may  be  duplicated  from  the  original. 

(5)  Preparation  of  Period  Report  Control  Deck: 

(a)  As  with  the  Period  Processor,  there  is  no  source  deck  for  the 
Period  Output  Processor.  Instead,  the  source  input  for  the  Period  Output  Pro¬ 
cessor  is  the  dump  tape  produced  by  the  last  DIVRUN  of  the  Period  Processor . 

(b)  The  control  deck  assembly  for  the  Period  Report  is  illustrateo 
in  Figure  A-9.  Only  the  optional  header  card  varies.  The  header  card  carries 
the  identification  title,  which  will  appear  at  the  top  of  each  page  of  the 
Period  Output  Reports;  it  may  be  any  length  up  to  80  characters.  The  header 
card  is  prepared  by  the  Control  Team  Programmer  after  coordination  with  the 
Control  Team.  A  sample  header  card  entry  is  as  follows: 

WAGCAP  TEST  GAME  1  MOBILE  DEFENSE  PERIOD  2 


(6)  Preparation  of  Period  Processor  Work  Request  Forms.  A  separate 
work  request  form  is  required  for  each  Period  Processor  deck  being  submitted 
to  the  DPFO.  See  Figures  A-10  and  A-ll. 


(a)  Item  1.  Enter  code  name  assigned  to  the  pro-*  - 

(b)  Item  2.  Enter  computer  core  requirements  for  tux.  :ob. 

(c)  Item  3: 

1^.  For  Start  of  Period,  enter  the  job  name  corresponding  to 
the  first  entry  on  the  first  control  card. 


2_.  For  Period  Restart,  enter  the  job  name  for  each  restart 
deck,  as  required  for  the  number  of  decks  being  submitted.  These  must 
correspond  to  the  first  entry  on  the  first  control  card  of  the  deck  to  be 
submitted. 

(d)  Item  4.  Enter  last  name  of  Control  Team  Programmer. 

(e)  Item  3.  Enter  telephone  extension  of  Control  Team  Programmer. 


Figure  A-9.  Period  Report  Deck  Assembly 
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(f)  Item  6.  Enter  estimate  of  machine  time  required. 

(g)  Items  7,  9,  and  10.  Leave  blank. 

(h)  Item  8.  Enter  U  for  unclassified. 


(i)  Item  11.  Enter  X  in  production  box.  ' 

(j)  Items  12  through  18.  Consult  with  the  Model  Maintenance 
Team  for  the  disk  pack  number  to  be  placed  in  the  first  row  of  column  12.  If 
the  data  file  must  be  reloaded  the  Control  Team  Programmer  checks  his  file  for 
the  tape  number  of  the  Orders  Input  Processor  Start  of  Period  tape.  This 
tape  was  created  on  NT  41  (see  Figure  A-6,  last  row).  This  step  is  crucial. 

If  an  incorrect  tape  number  is  used  the  program  will  execute,  and  the  discon¬ 
tinuity  will  not  be  evident  without  a  detailed  technical  review.  The  Orders 
Input  Processor  Start  of  Period  tape  number  is  inserted  in  the  second  row  of 
column  12,  and  its  label  is  entered  in  the  second  row  of  column  18  for  the 
Start  of  Period  only.  For  subsequent  increments  of  the  same  period  the  second^ 
row  of  column  12  is  left  blank,  and  the  second  row  of  column  18  will  contain 
the  label  of  the  dump  tape  of  the  previous  increment.  The  Control  Team 
Programmer  completes  the  third  and  fourth  rows  of  columns  13,  14,  15,  and  16 

as  shown  in  Figures  A-10  and  A-ll.  On  the  third  and  fourth  rows  of  column  17 
place  the  Julian  retention  date  of  each  tape  that  will  be  created  by  the  Period 
Processor.  Enter  on  each  row  of  column  18  the  label  desired  for  each  tape. 
These  labels  are  affixed  to  each  physical  reel  of  tape  and,  along  with  its 
reel  number,  is  the  identification  means  for  the  output  of  this  phase  of  the 
computer  processing.  The  tapes  produced  by  the  Period  Processor  are  as 
follows: 

,  NT  40  -  the  period  history  records  for  postgame  analysis 


.  NT  41  -  the  end  of  period  (or  increment)  dump  of  all  data  files 

A  dump  tape  is  created  at  the  end  of  each  time  increment  specified  in  the 
restart  time  in  the  data  card.  A  dump  tape  plus  an  exact  copy  of  the  dump  — 

tape  is  created  at  the  end  of  each  complete  increment.  The  careful  logging  j 

of  tape  numbers  and  labels  is  imperative  because  all  tapes  are  indistinguishable 
to  the  system. 

(k)  Items  19  through  24,  and  26.  Leave  blank. 

(l)  Item  25.  Enter  special  instructions  such  as  notification  of 
completion  and  relationship  with  other  runs. 

(7)  Logging  Out  of  Decks.  In  the  Log  Journal  the  Control  Team  Pro¬ 
grammer  enters  information  from  items  1  and  3  of  the  work  request  form  and 
in  the  Out  column,  enters  the  date  and  time  out. 
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(8)  Preparation  of  Period  Report  Work  Request  Form.  A  separate  work 
request  for  the  Period  Report  is  in  addition  to  the  Period  Processor  work 
requests  being  submitted  to  the  DPFO.  See  Figure  A-12. 

(a)  Item  1.  Enter  code  name  assigned  to  the  project. 

(b)  Item  2.  Enter  computer  core  requirements  for  this  job. 


(c)  Item  3.  Enter  GREPT. 

(d)  Item  4.  Enter  last  name  of  Control  Team  Programmer. 

(e)  Item  5.  Enter  telephone  extension  of  Control  Team  Programmer. 

(f)  Item  6.  Enter  estimate  of  machine  time  required. 

(g)  Items  7,  9,  and  10.  Leave  blank. 

(h)  Item  8.  Enter  U  for  unclassified. 

(i)  Item  11.  Enter  X  in  production  box. 

(j)  Items  12  through  18.  Consult  with  the  Model  Maintenance 
Team  for  the  disk  pack  numbers  to  be  placed  in  the  first  row  of  column  12. 

If  the  data  file  must  be  reloaded,  the  input  tape  on  NT  21  is  the  dump  tape 
created  on  NT  41  from  the  last  DIVRUN  in  the  series. 

(k)  Items  19  through  24,  and  26.  Leave  blank. 

(l)  Item  25.  Enter  special  instructions  such  as  notification  of 
completion  and  relationship  with  other  runs. 

(9)  Logging  Out  of  Deck.  In  the  Log  Journal  the  Control  Team  Pro¬ 
grammer  enters  Information  from  Items  1  and  3  of  the  work  request  form  and 

in  the  Out  column,  enters  the  date  and  time. 

(10)  Transportation  of  Deck  to  the  DPFO.  The  Control  Team  Programmer 
delivers  to  the  messenger  the  Period  and  Period  Processor  decks  and  both 
copies  of  the  prepared  work  request  forms.  The  messenger  transports  the  items 
to  the  DPFO,  using  transportation  he  summoned  at  the  time  he  was  alerted, 

and  delivers  the  items  to  the  DPFO  Job  Control  Point.  He  then  returns  to  the 
War  Game  Facility. 

(11)  Period  Processing.  At  this  point  the  DPFO  assumes  responsibility 
for  logging  the  job  into  the  facility,  establishing  a  priority  for  the  job, 
entering  the  job  onto  the  machine,  executing  the  job,  and  notifying  the  Control 
Team  Programmer  that  the  job  is  completed. 

(12)  Transportation  of  Deck  to  War  Game  Facility.  Upon  notification 
that  the  job  has  been  completed,  the  Control  Team  Programmer  instructs  the 
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messenger  to  pick  up  the  job.  The  messenger  summons  transportation  and  pro¬ 
ceeds  to  the  DPFO  Job  Control  Point,  where  he: 

(a)  Checks  the  job  to  see  that  the  work  request  form,  the  Period 
Processor  deck  or  decks,  and  the  printout  all  correspond,  and  that  no  materials 
from  other  jobs  have  been  included  inadvertently. 

(b)  Signs  for  the  completed  job  by  initialing  the  original  copy 
of  the  work  request  form,  which  he  leaves  at  the  DPFO. 

(c)  Transports  the  Period  and  Period  Output  Processor  deck  or  decks, 
the  printout,  and  the  duplicate  copy  of  the  work  request  form  to  the  War  Game 
Facility  and  delivers  all  items  to  the  Control  Team  Programmer. 

(13)  Logging  In  of  Deck.  In  the  Log  Journal,  the  Control  Team  Pro¬ 
grammer  finds  the  previous  Logging  Out  entry  for  this  job,  and  in  the  In  column 
enters  the  date  and  time  in. 

(14)  Filing  of  Work  Request  Form.  The  Control  Team  Programmer  files 
the  work  request  form  in  his  file  of  completed  work  request  forms. 

(15)  Separation  of  Period  Output  Reports.  The  Period  Output  Reports 
will  be  printed  on  four-part  paper  by  the  computer.  The  Control  Team  Programmer, 
after  review  of  the  output,  will  instruct  the  messenger  to  take  the  Period  Reports 
to  the  Data  Processing  Facility  at  Rucker  Hall  where  the  computer  output  is 
decollated.  The  messenger  will  wait  until  the  paper  is  decollated  and  then 
return  to  the  War  Game  Facility. 

(16)  Delivery  of  Printout.  The  Control  Team  Programmer  delivers  the 
technical  printout  and  one  copy  of  the  Period  Output  Reports  to  the  Model 
Maintenance  Team.  He  delivers  the  remaining  copies  of  the  Period  Output 
Reports  to  the  Chief  Controller  of  the  Control  Team.  This  procedure  completes 
the  processing  of  the  data  through  the  Period  Processor. 

f.  Summary.  Successful  completion  of  a  Period  Processor  computer  run 
ends  the  game  period  cycle  operations.  Clearly,  success  can  only  be  deter¬ 
mined  after  a  comprehensive  review  and  analysis  of  the  Period  Reports,  the 
subject  of  the  next  paragraph,  to  which  the  user  is  referred  to  evaluate 
the  success  of  the  computer  interface  for  the  period. 

3.  PERIOD  OUTPUT.  The  Period  Processor  produces  a  printout  for  technical 
diagnostic  purposes  and  force  reports  on  game  status  for  use  of  the  gaming 
staff.  Review  and  analysis  of  these  two  types  of  output  are  discussed 
separately.  *  •  • 

a.  Technical  Output: 

(1)  The  primary  purpose  c.  this  r-  ,/ut  is  to  provide  diagnostic 
data  for  the  analyst  to  determine  *ny  :chnical  errors  occurred  during 
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the  operation  of  the  DIVWAG  Model  Period  Processor.  Those  data  are  explained 
in  Volume  II,  Section  VIII,  Chapter  4. 


(2)  The  Model  Maintenance  Team  is  responsible  for  conducting  the 
analysis  for  technical  acceptability  of  the  game  period  processed.  They 
will  task  the  gaming  group  for  any  assistance  required  as  a  result  of  any 
technical  errors  or  anomalies  discovered. 

b.  Technical  Output  Analysis  Procedures: 

(1)  The  system  analyst  reviews  the  printout  with  regard  to  the 
following  three  areas  of  interest: 

(a)  Reasonableness  of  time  ranges  (game  time  at  the  end  of  the 
run,  job  compute  time,  and  channel  time). 

(b)  Legitimacy  of  termination. 

(c)  Interpretation  of  printed  diagnostic  statements. 

(2)  The  system  analyst  determines  the  nature  of  the  correction  to 

be  made  and  notes  this  on  the  printout,  indicating  specifics  of  the  correction 
when  applicable. 

(3)  The  system  analyst  initiates  correction  of  errors  in  accordance 
with  procedures  specified  in  Volume  II,  Section  VIII,  Chapter  4. 

(4)  At  the  completion  of  the  analysis,  the  Chief,  Model  Maintenance 
Team,  advises  the  Chief  Controller  as  to  the  results  of  the  analysis  and  the 
technical  validity  of  the  results. 


(a)  If  he  indicates  that  the  results  are  technically  invalid, 
he  will  indicate  the  reasons  therefor,  the  corrective  action  which  must  be 
taken  to  give  valid  results,  and  the  probable  implications  of  proceeding 
with  the  present  results. 

(b)  If  he  indicates  that  the  results  are  technically  valid,  he 
will  recommend  a  basis  for  proceeding  and  indicate  any  corrective  action 
that  may  be  desired  for  improving  the  processing. 

c.  Period  Output  Reports.  The  Period  Output  Processor  provides  the 
following  reports  on  game  status  for  each  game  period  processed.  Both  Blue 
and  Red  reports  are  provided. 


.  Intelligence  Report 
.  Force  Status  Report 
.  Force  Period  Planning  Report 
.  Barrier  and  Facility  Report 
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(1)  Intelligence  Report.  An  intelligence  report  is  provided  for 
each  division  size  force  gamed  in  the  simulation.  Figure  A-13  is  an  example 
of  such  a  report.  The  following  discussion  relates  to  that  figure  and  the 
circled  numbers  thereon. 

(a)  On  all  reports  the  first  four  items  are  a  standard  heading. 

The  game  identifier  (T)  is  an  optional  legend  that  can  be  input  during  pro¬ 
cessing  and  will  appear  on  all  pages  of  all  reports.  If  the  optional  input 
card  in  the  GREPORTS  deck  is  not  present,  then  the  legend  DIVWAG  WAR  GAME  is 
supplied  by  the  program.  The  date  and  time  (2)  are  the  real  time  that  the 
reports  were  prepared;  that  is,  the  wall  clock  time  at  the  end  of  the  pro¬ 
cessing.  Page  numbers  (3)  appear  as  indicated.  The  game  period  simulated 

(A)  gives  the  beginning  time  and  ending  time  of  the  actual  game  period  simulated. 
The  beginning  of  a  game  is  always  DAY  1  HR  0  MIN  0. 

(b)  The  report  title  (5)  identifies  the  force,  Blue  or  Red, 
receiving  the  report  and  an  index  (1,  2,  or  3)  identifying  the  specific 
division  force.  Four  intelligence  files  are  maintained,  one  for  Blue  and 
three  for  Red.  The  intelligence  index  (?)  is  assigned  at  the  time  the  target 
is  first  reported  and  is  a  permanent  part  of  the  report  through  all  parts  of 
the  model.  The  last  three  digits  of  the  intelligence  index  (6)  indicate 

the  sequence  number  assigned  that  particular  report.  The  first  two  digits 
in  a  five-digit  intelligence  index,  or  the  first  three  digits  in  a  six-digit 
intelligence  index,  will  identify  the  unit,  by  Unit  Status  File  record  num¬ 
ber,  acquiring  the  intelligence.  The  intelligence  indices  containing  more 
than  six  digits  are  internally  generated  and  do  not  provide  the  information 
as  explained  above.  If  new  information  is  reported  that  is  deemed  to  corre¬ 
spond  to  an  existing  report  the  information  is  consolidated  into  the  existing 
report  retaining  theexisting  intelligence  index.  The  information  items  are 
estimated  location  (7),  size  (§)  ,  activity  (3),  type  (lB) ,  and  direction  of 
movement  (ll)  ;  all  are  self-explanatory.  These  information  items  are  devel¬ 
oped  by  the  Intelligence  and  Control  Model,  and  a  full  understanding  of  that 
model  is  necessary  for  interpretation.  The  report  does  not  make  subtle  dis¬ 
tinctions  such  as  battery  or  troop  in  lieu  of  company  for  artillery  or 
caj«lry  units.  The  time  of  last  collection  (12)  and  the  number  of  sightings 
(lj)  indicate  how  often  and  how  long  ago  the  unit  was  reported  to  the 
division. 


(2)  Force  Status  Report.  The  Force  Status  Report  is  made  up  of 
three  parts,  in  addition  to  the  standard  headings  (T)-(a)  discussed  above. 

They  are  force  status  at  end  of  the  period,  activity  report  for  the  period, 
and  ground  movements  and  supporting  fires  during  the  period.  See  Figure  A-14. 

(a)  That  part  of  the  report  which  contains  the  unit's  status 
at  the  end  of  the  period  contains  the  unit  organization  and  current  situation 
(T).  Included  therein  is  the  unit  identity,  both  UID  and  UTD;  its  location; 
its  next  senior  headquarters;  its  directional  heading;  and  the  unit's  dimen¬ 
sions.  The  personnel  status  gives  the  on-hand  strength  and  the  percent 
of  authorized.  The  material  status  @  provides  the  equipment  by  item  code 
number,  the  amount  of  each  in  the  unit,  the  amount  in  unit  bulk  load,  the 
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Figure  A-13.  Example  Intelligence  Report 


Figure  A-14.  Example  Force  Status  Report 


total,  the  amount  authorized,  and  the  percent  of  authorized  on  hand.  Finally 
this  portion  of  the  report  identifies  the  unit's  subordinates  (8). 

(b)  The  period  activity  portion  of  the  report  (?)  describes, 
in  a  general  sense,  what  really  happened  to  the  unit  during  the  period  in 
the  sense  of  incoming  artillery  rounds  received,  incoming  nuclear  rounds, 
air  defense  capable  units  (ADCU)  encountered,  time  spent  in  ground  combat, 
and  air  sorties  flown  against  the  unit  by  either  close  air  or  attack  heli¬ 
copter.  The  report  lists  (l(5)  the  number  of  personnel  and  major  end  items 
of  equipment  lost  to: 

.  Artillery  conventional  fires 

.  Nuclear  weapons 

.  Air  defense  capable  units 

.  Ground  combat 

.  High-performance  aircraft 

.  Attack  helicopters 

In  addition,  the  total  losses  of  personnel  and  major  end  items  and  any  gains 
of  personnel  or  major  end  items  during  the  period  are  listed. 

(c)  The  final  portion  of  the  Force  Status  Report  (ll)  reports 
the  activities  conducted  by  the  unit.  In  the  example  at  Figure^A-14,  the 
number  of  ground  movements  and  the  distance  covered  were  reported.  The 
following  activities,  if  performed  by  a  unit,  will  be  reported. 

.  Number  of  artillery  rounds  fired  on  x  number  of  TACFIRE  missions 

.  Number  of  artillery  rounds  fired  on  x  number  of  DSL  fire  missions 

.  Number  of  nuclear  rounds  fired 

.  Number  of  sorties  flown  against  x  number  of  acquired  targets 

.  Number  of  sorties  flown  against  x  number  of  DSL  targets 

.  Number  of  obstacles  encountered  and  delay  time  in  minutes 
.  Number  of  engineer  tasks  completed 
.  Number  of  reconnaissance  sorties  flown 
.  Number  of  enemy  aircraft  fired  on 

.  Number  of  escort  and  lift  aircraft  provided  for  x  number  of 
airmobile  operations 

.  Number  of  airmobile  movements  conducted  over  x  number  of  meters. 
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(3)  Force  Period  Planning  Report.  The  Force  Period  Planning  Report 

serves  two  functions.  One  is  to  provide  a  convenient  list  of  units  in  task 
organization  order  for  map  plotting.  The  second  function  is  to  provide  a 
numerical  and  alphabetical  cross  reference  index  to  the  Force  Status  Report. 
Figure  A-15  is  an  example  of  the  Force  Period  Planning  Report.  The  standard 
headings  also  appear  on  this  report.  The  report  title  (T)  identifies 

the  force  covered  by  the  report. 

(a)  The  task  organization  section  (p  includes: 

1_.  The  UID  and  UTD  ©  of  each  unit. 

2_.  The  nonresolution  accounting  unit  indicator  (8)  or  the 
resolution  unit  indicator  (9).  The  model  makes  use  of  the  unit's  coordinates 
to  determine  whether  a  unit  is  a  resolution  or  a  nonresolution  unit.  Thus, 
nonresolution  units  have  zeros  for  their  x  and  y  coordinates  (§) ,  whereas 
resolution  units  have  nonzero  entries  for  their  x  and  y  coordinates  (?) . 

3_.  The  page  number  (^)  in  the  Force  Status  Report  on  which 
the  unit  can  be  found. 

4^  The  Unit  Status  File  record  number  (l^  .  All  units, 
both  resolution  and  nonresolution,  have  a  record  in  the  Unit  Status  File. 

The  Unit  Status  File  record  number  is  used  by  Model  Maintenance  Team  personnel 
for  tracing  technical  errors. 

(b)  The  cross  reference  index  $2)  provided  for  ease  of 
locating  a  particular  unit’s  Force  Status  Report.  The  collating  sequence  is 
alphabetical  followed  by  numerical;  thus,  in  any  character  position  of  the 
UID,  the  letters  A  through  Z  will  precede  the  numbers  0  through  9.  The 
grouping  of  UIDs  will  have  all  UIDs  that  only  vary  in  one  character  position 
together.  Within  this  group,  the  UID  will  be  listed  according  to  the  collat¬ 
ing  sequence,  with  all  letters  in  the  order  A  to  Z  followed  by  the  numbers  in 
the  order  0  to  9.  The  sorting  sequence  is  right  to  left  so  that  every  UID 
whose  second  character  from  the  left  is  the  same  will  appear  together.  Within 
the  group  every  UID  whose  third  character  from  the  left  is  the  same  will 
appear  together  and  similarly  for  the  fourth  through  eighth  characters;  thus, 
the  first  UID  would  be  B  or  R  followed  by  seven  letters  A,  and  the  last  UID 
would  be  B  or  R  followed  by  seven  nines,  if  these  UIDs  were  used  in  the  force. 

(4)  Barrier  and  Facility  Report.  This  report  provides  a  comprehensive 
listing  of  barriers  and  facilities  loaded  for  the  game,  and  their  known  status 
at  the  end  of  any  given  game  period.  Figure  A-16  is  an  example  of  part  of 
such  a  report.  The  standard  headings  ©-©  are  included. 

(a)  Each  barrier  and  each  facility  carries  its  own  unique 
mnemonic  ©  in  which  the  first  three  characters  designate  the  type  and  the 
last  three  designate  a  unique  facility  of  that  type  or  a  unique  segment  of 
that  type  barrier.  Each  also  carries  its  own  file  number  in  the  barrier/ 
facility  file  (6) . 
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Figure  A-15.  Example  Force  Period  Planning  Report 


(b)  Each  barrier  or  facility  is  defined  geographically  by 
coordinate  pair  end  points  (7) . 

(c)  The  type  (§)  is  a  numerical  designator  of  the  engineer 
task  related  to  that  specific  barrier  or  facility.  Related  directly  to  the 
type  is  the  task  size  associated  therewith. 

(d)  Activity  (?)  defines  the  engineer  event  associated  with 

the  barrier  or  facility.  The  example  in  Figure  A-16  represents  a  fixed  bridge. 
When  "ACTIVITY"  "NONE"  appears  it  is  obvious  that  no  one  has  been  assigned 
the  task  to  destroy  it.  This  is  verified  by  its  reported  status  U0)  and  (l^  . 


(e)  Activity  status  (12)  can  be  any  one  of  three  things: 


1 .  Name . 


2^  Resources  allocated. 

_3.  Work  in  progress. 

(f)  When  some  activity  is  to  occur  relative  to  building  or 
destroying  a  barrier  or  facility,  some  command  echelon  has  to  direct  it  (O)  , 
and  some  unit  will  be  tasked  to  perform  the  effort  (K)  . 

(g)  Intelligence  status  (15)  relates  to  the  question  on  who 
has  knowledge  of  the  existence  of  the  barrier  or  facility.  It  is  assumed 
that  both  forces  know  of  the  existence  of  all  natural  obstacles  and  of  most 
man-made,  fixed  facilities.  Dynamic  intelligence  functions  within  the  model  | 
report  on  and  update  intelligence  knowledge  on  all  others. 

(h)  Iii  its  current  configuration,  a  single  report  is  produced. 

The  Control  Team  is  responsible  to  ensure  that  only  the  appropriate  information 
is  received  by  respective  Player  Teams. 

d.  Period  Output  Report  Analysis.  The  Chief  Controller  has  overall 
management  responsibility  to  ensure  that  Period  Output  Reports  are  analyzed  ^ 
for  operational  acceptability.  He  will  task  the  Model  Maintenance  and  Analysis? 
Teams  as  required  to  resolve  any  errors/data  problems  that  appear  to  be 
model-related.  In  addition,  each  Player  Team  Chief  is  specifically  charged 
to  conduct  a  detailed  analysis  of  his  respective  Period  Reports  and  to 
report  his  findings  to  the  Chief  Controller.  If  any  element  is  considered 
by  the  Team  Chief  to  be  operationally  unacceptable,  that  fact  is  reported 
in  writing,  giving  reasons. 

(1)  Analysis  by  Control  Team: 

(a)  The  Intelligence  Report  is  reviewed  for  irregularities  in  * 
target  acquisitions. 


\  , 1  • 


(b)  The  Force  Status  Report  ts  reviewed  for: 

1_.  Determination  of  status  of  major  units. 

1_.  Irregularities  in  major  events  occurring  during  the 

period . 

_3.  Irregularities  in  movements  of  units. 

Irregularities  in  personnel  strengths. 

_5.  Irregularities  in  mission  essential  equipment. 

6u  Irregularities  in  supply  consumption  and  resupply. 

T_.  Irregularities  in  battle  engagement  losses. 

8^.  Irregularities  in  artillery  losses. 

9.  Irregularities  in  air  ground  engagement  losses. 

10.  Irregularities  in  personnel  losses  (too  high,  too  low). 

11.  Irregularities  in  mission  essential  equipment  losses 

(too  high,  too  low,  for  a  particular  weapon  system). 

(c)  The  Barrier  and  Facility  Report  is  reviewed  for  irregularities 
in  location  and  status  of  barriers. 

(d)  The  Force  Period  Planning  Report  is  used  only  for  cross- 
referencing  to  other  reports. 

(2)  Analysis  by  Player  Teams: 

(a)  The  Intelligence  Report  is  analyzed  for  irregularities  in 
target  acquisitions. 

(b)  The  Force  Status  Report  is  analyzed  for: 

JL  Determination  of  status  of  units. 

2.  Irregularities  in  events  occurring  during  the  period. 

2/  Irregularities  in  movement  of  units. 

£.  Irregularities  in  unit  personnel  strengths. 

5_.  Irregularities  in  unit  mission  essential  equipment. 

6.  Irregularities  in  units'  battle  engagement  losses. 
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]_.  Irregularities  in  artillery  losses. 

,8.  Irregularities  in  air  ground  engagement  losses, 
j?.  Irregualrities  in  unit  personnel  losses  (too  high, 

too  low) . 

10.  Irregularities  in  unit  mission  essential  equipment 
losses  (too  high,  too  low,  for  a  particular  weapon  system). 

(c)  Player  teams  use  the  Force  Period  Planning  Report  as  a 
convenient  cross-reference  to  find  the  page  in  the  Force  Status  Report  of 
high  interest  units.  They  also  use  it  to  update  unit  locations  on  the  game 
map. 


(d)  Each  Player  Team  reviews  the  Barrier  and  Facility  Report 
for  irregularities  in  location  and  status  of  barriers. 

(e)  At  the  completion  of  the  Player  Team  analysis,  the  Player 
Team  Chief  advises  the  Chief  Controller  as  to  the  results  of  the  analysis 
for  his  forces  and  the  operational  acceptability  of  the  results  insofar  as 
related  to  his  team. 


_1.  If  he  indicates  that  the  results  are  operationally 
unacceptable,  he  will  indicate  the  reasons  therefor,  the  corrective  action 
that  must  be  taken  to  give  acceptable  results,  and  the  probable  implications 
of  proceeding  with  the  present  results. 

,2.  If  he  indicates  that  the  results  are  operationally 
acceptable,  he  will  recommend  a  basis  for  proceeding  and  indicate  any 
corrective  action  that  may  be  desired  for  improving  the  process  or  results. 

e.  Exploitation  of  the  Review  and  Analysis  of  Period  Output: 

(1)  Based  on  the  advice  of  the  Chief,  Model  Maintenance  Team, 
regarding  the  technical  validity  of  the  results  and  the  Control  Team  analysis 
of  the  Period  Reports,  the  Game  Director  makes  the  final  decision  as  to  the 
operational  acceptability  of  the  results. 

(2)  If  his  decision  is  negative,  he  will  advise  the  Chief,  Model 
Maintenance  Team,  and  the  Chief  Controller  to  initiate  corrective  action  and 
will  indicate  the  scope  and  extent  of  corrective  action  to  be  taken. 

(3)  If  his  decision  is  positive,  he  will  advise  the  Chief,  Model 
Maintenance  Team,  and  the  Chief  Controller  to  update  the  game  and  will  advise 
them  as  to  any  corrective  action  desired  in  connection  therewith. 

(4)  Procedures  for  correction  of  errors  are  as  follows. 


(a)  Introduction: 

1^.  After  completion  of  the  error  analysis  it  will  be 
necessary  to  correct  errors,  as  required,  and  then  to  either  initiate  a  rerun 
or  update  the  game.  This  subparagraph  deals  with  the  correction  of  errors. 

2.  Procedures  for  correction  of  errors  vary  according  to  the 
type  of  correction  required.  Four  types  of  correction  are  encountered:  cor¬ 
rections  to  the  Orders  Input,  corrections  to  the  DIVWAG  Model  logic  or  technical 
rules,  corrections  in  ADP  processing  or  control  cards,  and  corrections  to 
constant  input  data. 

(b)  Technical  and  Operational  Errors.  Irregularities  may 
indicate  either  operational  or  technical  errors. 

1_.  Operational  errors  may  be  due  to  faulty  composition  of 
scenarios  or  data  or  exceeding  some  limiting  constraint  of  the  DIVWAG  Model. 
These  types  of  errors  may  be  corrected  by  preparing  new  code  sheets  or  revised 
cards. 


2_.  Technical  errors  may  be  due  to  faulty  model  logic  or 
technical  rules.  Correction  of  this  type  of  problem  is  the  responsibility 
of  the  Chief  of  the  Model  Maintenance  Team. 

_3.  If  the  results  were  unacceptable,  either  technically  or 
operationally,  and  the  results  of  this  game  period  are  critical  to  the  results 
evaluation  analysis,  initiate  a  rerun  of  the  Period  Processor.  If  the  results 
of  this  game  period  are  not  critical  to  the  results  evaluation  analysis, 
initiate  update  of  the  game  as  indicated  in  Paragraph  A  below. 

ji.  Responsibility  for  correction  of  errors  rests  with  the 
element  responsible  for  the  error  analysis.  Responsibility  for  the  decision 
to  rerun  the  Period  Processor  or  update  the  game  rests  with  the  Game  Director. 
The  Chief,  Model  Maintenance  Team,  is  responsible  for: 

.  In  consultation  with  the  Control  Team,  determining  the  nature 
of  all  model  logic  or  technical  rule  corrections  to  be  made 
that  will  affect  evaluation  results. 

.  Effecting  the  model  logic  or  technical  rule  corrections  agreed 
upon. 

.  Advising  the  Chief  Controller  and  the  Game  Director  in  advance 
on  the  probable  degree  of  effects  on  evaluation  data  of  any 
corrections  to  be  undertaken. 

The  Chief  Controller  is  responsible  for: 

Providing  Control  Team  assistance  to  the  Chief,  Model  Maintenance 
Team,  in  determining  the  nature  of  all  model  logic  or  technical 
rule  corrections  to  be  made  that  will  affect  evaluation  results. 
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.  Making  recommendations  to  the  Game  Director  regarding  the 
rerunning  of  a  game  period. 

(c)  Corrections  to  ADP  Processing.  These  corrections  may  involve 
either  the  work  request  form  or  the  actual  processing  in  the  computer  system. 

_1 .  Work  Request  Form  Errors.  Correction  of  human  errors 
encountered  in  preparation  of  the  work  request  form  is  effected  by  preparation 
of  a  new  work  request  form  with  correct  information. 

a_.  Responsibility.  The  Control  Team  Programmer  is 
responsible  for  making  this  type  of  correction. 


b^.  Post-correction  Procedure.  Resubmit  work  request 
form  with  related  input  material. 


2.  Processing  Errors  in  DPFO.  These  errors  may  involve 
hardware  malfunctions  or  human  operator  errors.  In  either  case  the  output 
or  portions  of  the  output  may  be  unusable,  and  a  rerun  or  partial  rerun  may 
be  required. 
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a^  Responsibility: 

.  The  DPFO  is  responsible  for  correcting  the  causes  of  its  in-house 
errors. 

.  The  Control  Team  Programmer  is  responsible  for  coordination  of 
the  problem  with  DPFO,  Chief  Controller,  and  Chief,  Model 
Maintenance  Team,  for  determination  of  the  extent  of  usable 
portions  of  the  output,  and  the  extent  of  rerun  or  partial 
rerun  required. 

.  The  Chief  Controller  is  responsible  for  making  the  decision  as 
to  the  extent  of  usable  and  unusable  portions  of  the  output, 
the  extent  of  rerun  or  partial  rerun  required,  and  for 
initiation  of  rerun  or  partial  rerun. 

Jb.  Post-correction  Procedure.  The  ADP  Control  Team 
Programmer  resubmits  the  work  request  form  with  related  input  material  as 
required  by  the  situation. 

A.  UPDATING  OF  GAME.  There  are  two  separate  facets  to  updating  the  game: 
updating  displays  and  updating  game  operational  records. 

a.  Updating  Displays: 

(1)  Purpose.  The  updating  of  displays  serves  two  primary  purposes: 
it  provides  the  basis  for  a  visual  presentation  of  the  end-of-per iod  status 
report  (in  the  final  game  period  this  becomes  the  end-of-game  status  report); 


and,  for  all  game  periods  except  the  final  one,  it  provides  the  basis  for 
planning  the  military  action  for  the  subsequent  game  period. 


(2)  Responsibility.  The  Chief  Controller  and  Chief  of  each  Player 
Team  is  responsible  for  updating  and  arranging  for  the  necessary  photography 
of  situation  maps  and  projection  screens  in  use  in  his  game  room. 

(3)  Procedures.  Updating  of  displays  from  the  period  reports  and 
arrangements  for  photography  will  be  conducted  as  follows: 

(a)  Using  transparent  map  symbols,  groups  post  maps  and  screens, 
get  approval  of  the  final  display,  remove  screens  to  photography  room,  attach 
legend  as  shown  in  Figure  A-17,  and  inform  the  graphics  technician  on  the 
number  of  transparencies  required. 

(b)  The  graphics  technician  prepares  the  transparencies,  prepares 
a  camera-ready  hard  copy  of  each  screen's  display,  and  informs  the  proper  group 
the  work  is  completed. 

(c)  The  screen  is  retrieved  by  the  originator  who  passes  the 
camera-ready  hard  copy  to  the  Control  Team  for  game  records  files,  and  who 
distributes  transparencies  as  dictated  by  the  Chief  Controller. 


GAME  PERIOD 

GAME _ 

LOG  NR _ 

DTG _ 

ACTUAL  DATE 


01  2345  SCALE  10 


Figure  A-17.  Display  Screen  Legend 
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Game  operational  records  consist 


b.  Updating  Game  Operational  Records, 
of  the  data  listed  below: 

.  Game  Period  Concept. 

.  Orders  Input  COMPILE. 

.  Period  Reports. 

.  Graphic  Displays. 

.  Period  Narratives. 

(1)  The  Game  Period  Concept  for  each  period  becomes  a  game  document 
which  is  included  in  the  Final  Report.  This  document,  for  each  period, 
should  be  put  in  final  form  during  the  time  the  Player  Teams  are  preparing 
their  unit  scenarios  for  that  period. 

(2)  The  final  DSL  COMPILE  listing  of  the  game  orders  input  for  each 
period  becomes  a  game  document.  These  listings  are  not  included  in  the  Final 
Report.  They  are  retained  at  the  War  Game  Facility  for  review  by  authorized, 
interested  parties. 

(3)  Period  Output  Reports  for  each  game  period  become  game  documents. 
They  are  not  included  in  the  Final  Report.  They  are  retained  at  the  War  Game 
Facility  for  review  by  authorized,  interested  parties. 

(4)  Graphic  displays  for  each  game  period  become  game  documents 
which  are  included  in the  Final  Report.  They  should  be  prepared  as  early  as 
possible  after  the  Game  Director  has  approved  the  acceptability  of  the  period 
results . 


(5)  Period  Narratives  for  each  game  period  become  game  documents  which 
are  included  in  the  Final  Report.  As  a  general  rule  the  period  narrative  pre¬ 
paration  is  delayed,  when  compared  with  the  other  documentation.  The  reason 
is  straightforward.  The  first  priority,  once  a  game  period  is  determined  " 

acceptable,  usually  is  to  set  up  another  game  period.  The  theory  is  that  the 
gaming  group  can  prepare  a  game  period  narrative  for  a  given  game  period  while 
the  following  period  is  being  processed  by  the  computer. 


« 
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APPENDIX  B 


DIVWAG  SCENARIO  LANGUAGE  REFERENCE  MANUAL 


1.  INTRODUCTION.  The  essential  components  of  the  DIVWAG  Scenario  Language 
(DSL),  as  of  any  language,  are  a  vocabulary;  or  set  of  symbols,  words,  or 
phrases  with  specified  meanings;  and  a  syntax,  or  set  of  rules  for  combining 
vocabulary  elements.  With  DSL  the  vocabulary  is  limited  to  a  small  set  of 
elements,  and  the  syntax  is  relatively  rigid;  that  is,  few  syntactic  options 
exist.  Within  the  DSL  syntax,  the  highest  level  of  composition  is  the  Unit 
Scenario  and  the  Battle  Paragraph.  This  level  parallels  the  paragraph  of 
the  English  language,  generally  defined  as  being  composed  of  one  or  more 
sentences  and  dealing  with  one  point.  A  Unit  Scenario  contains  the  DSL 
commands  for  one  unit  within  the  DIVWAG  system,  and  a  Battle  Paragraph  con¬ 
tains  the  definition  and  instructions  for  one  battle  within  the  Ground  Combat 
Model  of  the  Period  Processor.  As  the  paragraph  of  the  English  language 
generally  contains  an  introductory  sentence  followed  by  a  number  of  elaborat¬ 
ing  sentences,  so  must  a  Unit  Scenario  or  a  Battle  Paragraph  contain  an 
introductory  section  and  an  elaborating  body.  As  a  sentence  of  the  English 
language  generally  expresses  one  thought  and  concludes  with  appropriate  end 
punctuation,  so  must  each  piece  of  a  Unit  Scenario  or  a  Battle  Paragraph. 

As  punctuation  is  critical  to  a  proper  understanding  of  written  English,  it 
is  also  critical  to  proper  use  of  DSL.  DSL  differs  from  a  language  used  for 
human  communication  in  one  highly  significant  aspect,  semantic  flexibility. 

In  the  English  language  a  sentence  could  be  interpreted  as  having  several 
meanings,  and  a  single  thought  could  be  expressed  in  a  multitude  of  ways. 

In  DSL,  an  order  has  only  one  meaning,  and  there  is  only  one  way  to  express 
an  order. 

2.  DSL  COMPOSITION: 

a.  General.  The  highest  level  of  composition  within  the  DSL  syntax  is 
the  Unit  Scenario  or  the  Battle  Paragraph.  Each  contains  an  Introductory 
section  and  an  elaborating  body.  Each  statement  of  the  introductory  sections 
or  of  the  elaborating  body  is  similar  to  a  sentence  of  the  English  language 
and  must  end  with  a  period.  Any  other  use  of  a  period  within  DSL  is  illegal; 
thus,  decimal  points  are  not  permitted  and,  although  abbreviations  are 
possible  within  the  vocabulary,  they  are  not  denoted  by  the  period.  The 
building  blocks  for  a  statement  are  order  clauses,  conditional  clauses,  and 
labels.  In  the  following  paragraphs,  an  order  clause  is  represented  by  the 
symbol  0,  a  conditional  clause  by  the  symbol  C,  and  a  label  by  the  symbol  L. 
Where  examples  are  given  below,  the  prototype  order  clause  STAY  UNTIL  011200 
will  be  used,  the  prototype  conditional  clause  TIME  LESS  THAN  011830  will. be 
used,  and  the  prototype  label  ABC  will  be  used.  Statements  may  not  exceed 
400  characters  in  length. 

b.  Unit  Scenarios.  A  Unit  Scenario  contains  the  set  of  DSL  orders  to 
be  followed  by  one  unit  through  the  course  of  the  game  period  for  which  the 
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DSL  is  prepared.  A  Unit  Scenario  contains  one  introductory  statement  and  at 
least  one  elaborating  statement. 

(1)  Unit  Identification.  The  unit  identification  is  the  first 
statement  of  each  Unit  Scenario.  It  contains  the  characters  ID:  followed 
by  the  eight-character  unit  identification  (UID)  of  the  unit  to  follow  the 
orders  contained  in  the  scenario.  For  example: 

ID:B1234ABC. 

The  colon  and  period  must  be  present  as  in  the  example.  The  UID  must  be 
composed  of  exactly  eight  alphanumeric  (letters  of  the  alphabet  or  Arabic 
numerals)  characters,  the  first  of  which  must  be  B  or  R. 

(2)  Commands .  Commands  comprise  the  elaborating  body  of  a  Unit 
Scenario.  Each  unit  identification  statement  must  be  followed  by  at  least 
one  command.  There  is  no  practical  limit  on  the  number  of  commands  which 
may  appear  within  one  Unit  Scenario.  A  command  is  composed  of  an  optional 
label,  one  or  more  optional  conditional  clauses,  and  exactly  one  mandatory 
order  clause. 


(a)  Command  Syntax.  A  command  may  be  written  in  one  of  the  four 
following  basic  forms: 


0. 

L:0 . 

IF  C,  THEN  0. 

L:IF  C,  THEN  0. 

Using  the  prototypes  introduced  above,  these  forms  are  in  actual  DSL  examples: 

STAY  UNTIL  011200. 

ABC: STAY  UNTIL  011200. 

IF  TIME  LESS  THAN  011830,  THEN  STAY  UNTIL  011200. 

ABC: IF  TIME  LESS  THAN  011830,  THEN  STAY  UNTIL  011200. 

The  following  rules  of  syntax  must  be  observed: 

1..  If  a  label  is  present,  it  must  be  the  first  element  of 

the  command. 

2^.  If  a  label  is  present,  it  must  be  followed  by  a  colon. 

If  a  conditional  clause  is  present,  it  must  be  stated 
before  the  mandatory  order  clause  and  after  the  label  (if  used). 

4^  If  a  conditional  clause  is  present,  it  must  be  introduced 
by  the  keyword  IF  and  it  must  be  followed  by  a  comma  and  the  keyword  THEN, 
in  that  order. 


5_.  The  order  clause  must  be  the  final  clause  of  a  command. 

6_.  The  order  clause  must  be  followed  by  a  period. 

(b)  Syntax  for  Conditional  Expansion.  The  basic  command  forms 
containing  conditionals  may  be  expanded  to  contain  more  than  one  conditional 
in  the  following  forms: 

IF  C  AND  IF  C  AND  IF  C,  THEN  0. 

L: IF  C  AND  IF  C  AND  IF  C,  THEN  0. 

IF  C  OR  IF  C  OR  IF  C,  THEN  0. 

L:IF  C  OR  IF  C  OR  IF  C,  THEN  0. 

In  using  the  conditional  expansion  feature,  the  following  additional  rules 
of  syntax  must  be  followed: 

JL.  The  logical  keywords  AND  and  OR  may  not  both  appear  in 

one  command. 

_2,  The  first  conditional  clause  is  introduced  by  the  keyword 
IF;  all  following  conditional  clauses  are  introduced  by  the  keywords  AND  IF 
or  OR  IF. 


.3.  The  last  conditional  clause  is  followed  by  a  comma  and 
the  keyword  THEN. 

(c)  Command  Components: 

JL.  The  order  clause  within  a  command  must  be  composed  of  one 
of  the  orders  within  the  DSL  vocabulary  with  any  appropriate  modifiers. 

2.  The  conditional  clauses  within  a  command  must  be  composed 
of  conditionals  contained  within  the  DSL  vocabulary  with  appropriate  modifiers. 

j).  The  label  within  a  command  must  be  composed  of  not  more 
than  three  alphanumeric  characters.  Each  label  within  one  Unit  Scenario  must 
be  unique.  Labels  are  used  to  identify  specific  commands  within  a  Unit  Sce¬ 
nario.  The  use  of  labels  is  treated  at  length  in  paragraph  6.  The  keyword 
ID  may  not  be  used  as  a  label  since  it  is  associated  with  unit  identification. 

(3)  Unit  Scenario  Execution.  A  Unit  Scenario  contains  all  commands 
to  be  followed  by  the  unit  identified  in  the  unit  identification  statement 
during  the  game  period  for  which  the  scenario  was  written.  A  unit  will  follow 
commands  only  if  it  is  a  resolution  unit  and  if  it  has  a  personnel  strength 
of  at  least  one  man.  (It  is  assumed  that  the  reader  is  familiar  with  the. 
concept  of  resolution  units  within  the  DIVWAG  system.)  Since  a  nonresolution 
unit  is  not  actually  active  within  the  Period  Processor ,  any  Unit  Scenario 
for  a  nonresolution  unit  will  be  ignored.  The  Unit  Scenario  for  any  resolu- 
cion  unit  having  less  than  one  man  is  also  Ignored. 
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(a)  Sequencing.  The  first  command  in  a  Unit  Scenario  is  always 
acted  upon  first.  When  execution  of  one  command  is  completed,  execution  of 
the  succeeding  command  is  initiated.  This  direct  sequencing  of  commands  can 
be  overridden  by  the  proper  use  of  labels  and  the  GO  TO  order,  or  the  Battle 
Paragraph,  as  discussed  in  paragraph  6. 

(b)  Execution  of  One  Command: 

JL.  Conditionals.  Upon  receipt  of  a  command  which  contains 
a  conditional  clause  or  clauses,  the  condition  is  checked  prior  to  execution 
of  the  order  clause.  If  the  condition  stated  in  the  conditional  clause  does 
exist,  the  order  clause  is  executed.  If  the  condition  stated  in  the  condi¬ 
tional  clause  does  not  exist,  the  order  clause  is  Ignored  and  the  next  command 
is  executed.  Processing  of  a  command  wherein  the  expanded  conditional  feature 
is  used  is  identical  except  that  all  conditional  clauses  are  checked.  If  the 
logical  AND  keyword  is  used,  Che  condition  stated  in  each  conditional  clause 
must  exist  for  execution  of  the  order  clause.  If  the  logical  OR  keyword  is 
used,  the  order  clause  is  executed  if  the  condition  stated  in  any  one  (or  ^ 

more)  of  the  conditional  clauses  exists.  In  either  case,  the  next  command 
is  executed  if  the  appropriate  conditional  criteria  are  not  met. 

2.  Order  Clause.  In  the  absence  of  conditional  clauses  or 
the  presence  of  appropriate  conditional  criteria,  the  order  clause  of  a 
command  is  executed .  Duration  of  the  event  initiated  by  an  order  clause 
depends  on  the  nature  of  the  clause.  Generally,  the  Unit  Scenario  is  not 
reentered  until  execution  of  the  event  initiated  by  the  order  clause  has  been 
completed.  Exceptions  are  discussed  in  paragraph  6. 

(A)  Unit  Scenario  Preparation.  Unit  Scenarios  are  written  on  standard 
program  coding  sheets  in  free  form;  that  is,  the  first  character  can  be 
written  in  any  column  of  the  form,  and  spacing  between  characters  or  a  group 
of  characters  can  be  used  to  improve  readability.  As  many  lines  as  needed  may 
be  used  for  one  command,  each  line  representing  a  punched  card.  Each  command 
must  begin  with  a  new  line  (new  card).  The  information  on  the  form  is  then 
key  punched  on  standard  cards,  and  the  cards  are  assembled  in  proper  sequence  ^ 
to  become  unit  scenarios  within  the  source  deck. 

c.  Battle  Paragraphs.  One  Battle  Paragraph  serves  to  identify  each 
battle  grouping  (battle)  within  the  Ground  Combat  Model  of  the  Period  Processor, 
to  identify  the  units  involved  in  that  battle,  to  establish  the  conditions 
for  termination  of  the  battle,  and  to  identify  the  command  within  their  re-  * 

spective  Unit  Scenarios  that  each  involved  unit  is  to  follow  upon  termination 
or  the  battle.  A  Battle  Paragraph  contains  two  introductory  statements  and 
at  least  one  elaborating  statement, 

* 

(1)  Battle  Identification  (BID).  The  battle  identification  is  the 
first  statement  of  each  Battle  Paragraph.  It  contains  the  characters  BATTLE: 
followed  by  the  name  associated  with  the  battle  (BID).  For  example: 

BATTLE: BULGE. 
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The  colon  and  period  must  be  present  as  In  the  example.  The  battle 
identification  (BID)  must  be  composed  of  not  more  than  eight  alphanumeric 
characters;  and,  within  one  game  period,  each  BID  must  be  unique. 

(2)  Battle  Declaration.  The  battle  declaration  is  the  second 
statement  of  each  Battle  Paragraph.  It  contains  the  phrase  SURFACE  UNITS:, 
followed  by  a  list  of  the  UIDs  of  units  which  are  to  be  actively  engaged  in 
the  battle  or  are  to  respond  to  battle  conditionals  contained  in  the  Battle 
Paragraph.  For  example: 

SURFACE  UNITS:B123ABCD,B111222B,RAB12345. 

The  colon  must  be  present,  the  UIDs  must  be  separated  by  commas,  and  the 
period  must  be  present,  as  in  the  example.  No  more  than  34  UIDs  may  be  used, 
and  no  more  than  17  UIDs  on  either  side  -(Blue  or  Red)  are  permitted. 

(3)  Battle  Conditionals.  Battle  conditionals  comprise  the  elaborating 
body  of  a  Battle  Paragraph.  Each  battle  declaration  statement  must  be  followed 
by  at  least  one  battle  conditional.  There  is  no  practical  limit  on  the 
number  of  battle  conditionals  in  one  Battle  Paragraph.  A  battle  conditional 

is  composed  of  one  conditional  clause  and  a  series  of  labels,  where  the 
number  of  labels  must  equal  the  number  of  units  listed  in  the  battle  declara¬ 
tion  statement. 

(a)  Battle  Conditional  Syntax.  A  battle  conditional  must  be 
written  in  one  of  the  following  forms: 

WHEN  C,  THEN  L,L,L. 

WHEN  C,  AND  WHEN  C,  AND  WHEN  C,  THEN  L,L,L. 

WHEN  C,  OR  WHEN  C,  OR  WHEN  C,  THEN  L,L,L. 
or,  using  the  prototypes  listed  above  form  one  becomes: 

WHEN  TIME  LESS  THAN  011830,  THEN  ABC, ABC, ABC. 

The  following  rules  of  syntax  must  be  observed: 

JL.  The  logical  keywords  AND  or  OR  may  not  both  appear  in  one 

command . 


.2.  The  first  conditional  clause  is  introduced  by  the  keyword 
WHEN;  all  following  conditional  clauses  are  introduced  by  the  keywords  AND 
WHEN  o  OR  WHEN. 


3^  The  last  conditional  clause  is  followed  by  a  comma  and  the 

keyword  THEN. 
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4_.  The  number  of  labels  must  agree  with  the  number  of  units 
listed  in  the  battle  declaration  statement. 

,5.  Labels  must  be  separated  by  commas. 

6_.  The  final  label  must  be  followed  by  a  period. 

Each  unit  in  the  battle  declaration  statement  must  have 

a  Unit  Scenario. 

S_.  The  nth  iisted  unit  in  the  battle  declaration  must  have 
in  its  Unit  Scenario  a  command  which  has  the  nth  label  listed  in  the  battle 
conditional. 


(b)  Battle  Conditional  Execution: 

,1.  Timing.  The  list  of  battle  conditional  statements  within 
a  Battle  Paragraph  is  reviewed  after  each  simulation  increment  of  the  named 
battle  within  the  Period  Processor.  } 

2.  Sequence.  Battle  conditionals  within  a  Battle  Paragraph 
are  executed  in  the  sequence  in  which  they  appear  in  the  paragraph. 

3_.  Condition  Met.  If,  in  the  course  of  executing  battle 
conditionals,  the  condition  stated  in  a  given  conditional  clause  does  exist, 
the  battle  is  terminated  (another  battle  increment  is  not  scheduled  in  the 
Period  Processor);  and  each  unit  listed  in  the  battle  declaration  statement 
is  immediately  scheduled  to  execute  the  command  within  its  own  Unit  Scenario 
which  has  a  label  matching  the  label  of  that  battle  conditional  associated 
with  that  unit.  Association  of  units  in  the  battle  declaration  and  labels 
in  the  battle  conditional  is  by  position;  that  is,  the  nth  listed  unit  is 
associated  with  the  nth  listed  label. 

4..  Condition  Not  Met.  If  at  the  time  of  execution,  the 
condition  listed  in  a  battle  conditional  is  not  met,  processing  continues 
with  the  next  battle  conditional.  When  all  conditionals  in  a  Battle  Paragrap  ^ j 
have  been  processed,  and  none  of  the  stated  conditions  exists,  a  new  battle 
increment  is  scheduled  in  the  DIVWAG  Period  Processor. 

3.  DSL  ORDER  CLAUSES: 

* 

a.  General.  The  previous  paragraph  introduced  the  order  clause  and  the 
the  conditional  clause  as  components  of  a  DSL  statement.  This  paragraph 
presents  the  elements  of  a  DSL  order  clause,  and  paragraph  4  presents  elements 
of  a  DSL  conditional  clause, 

% 

(1)  Each  order  clause  is  composed  of  exactly  one  basic  order,  a 
variable  number  of  order  modifiers,  and  a  variable  number  of  data  elements. 

In  the  following  discussion,  elements  of  DSL  will  always  be  written  in  upper 
case  letters  to  differentiate  from  the  accompanying  narrative. 
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(2)  The  DSL  Compiler  does  not  recognize  English  words.  It  recognizes 
DSL  elements.  For  example,  the  compiler  recognizes  the  basic  order  FIRE  as 
one  DSL  element.  It  also  recognizes  the  basic  order  FIRE  ON  TARGETS  OF 
OPPORTUNITY  as  one  DSL  element.  The  user  must  take  care  to  provide  the  total 
DSL  element  when  preparing  DSL  orders. 

(3)  Order  modifiers  may  be  mandatory,  exclusive,  or  optional.  A 
mandatory  order  modifier  is  one  which  must  appear  each  time  the  basic  order 
with  which  it  is  associated  appears.  A  set  of  exclusive  order  modifiers  is 
a  group  of  modifiers,  exactly  one  of  which  must  appear  each  time  the  asso¬ 
ciated  basic  order  appears.  An  optional  order  modifier  is  one  which  may  appear 
with  the  associated  basic  order  but  is  not  required  by  the  DSL  Compiler. 

(4)  A  data  element  may  be  associated  with  a  basic  order  or  with  an 
order  modifier.  Data  elements  are  never  optional;  that  is,  where  a  data 
element  is  associated  with  a  basic  order  or  an  order  modifier,  the  data 
element  must  be  present. 

(5)  The  first  element  of  an  order  clause  is  always  a  basic  order. 

If  a  data  element  is  associated  with  a  basic  order,  it  is  always  the  second 
element  of  an  order  clause.  Order  modifiers  and  associated  data  may  be 
written  after  the  basic  order  and  its  data  element  (if  any)  in  any  sequence, 
with  the  limitation  that  a  data  element  associated  with  any  modifier  must 
immediately  follow  the  modifier.  Punctuation,  or  any  entry  not  specifically 
identified  as  part  of  a  DSL  element,  is  not  allowed. 

b.  DSL  Basic  Orders.  Basic  DSL  orders  are  grouped  within  b!x  generic 
categories:  stay,  move,  engage,  engineer,  transfer,  and  pseudo  orders.  These 
categories  contain  basic  orders  for  which  the  simulated  activity  is  generally 
similar.  In  most  cases,  the  various  orders  generate  different  secondary 
actions  which  are  discussed  with  the  appropriate  basic  order. 

(1)  Stay  Activity  Orders.  Units  with  a  stay  activity  are  motionless. 
They  will  consume  class  I  and  class  III  supplies.  If  on  the  ground,  they  may 
be  assessed  by  area  fires  and  by  aerial  attack  and,  if  air  defense  units,  may 
fire  upon  enemy  aircraft.  Other  capabilities  of  units  with  stay  activity 
orders  depend  upon  the  specific  order. 

(a)  STAY,  The  STAY  order  requires  one  of  the  exclusive  modifiers 
FOR  (a  specified  period  of  time)  or  UNTIL  (a  specified  time).  For  example: 

STAY  FOR  1  HOUR. 

STAY  UNTIL  010230. 

If  the  unit  is  an  artillery  unit  it  will  enter  the  TACFIRE  Model-  of  its 
division  automatically  and  will  fire  upon  targets  if  so  directed  by  TACFIRE. 
This  is  also  the  default  order.  If  a  resolution  unit  has  no  Unit  Scenario, 
or  if  all  commands  in  its  Unit  Scenario  are  completed,  the  Period  Processor 
will  automatically  generate  a  STAY  UNTIL  (end  of  the  game  period)  for  the 
unit. 
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(b)  FIRE  ON  TARGETS  OF  OPPORTUNITY.  This  order  should  only  be 
given  to  artillery  units.  It  requires  the  same  modifiers  as  the  STAY  order 
and,  for  an  artillery  unit,  has  the  same  effect  as  a  STAY  order.  Examples: 

FIRE  ON  TARGETS  OF  OPPORTUNITY  FOR  30  MIN. 

FIRE  ON  TARGETS  OF  OPPORTUNITY  UNTIL  011230. 

(c)  PREPARE.  The  PREPARE  order  requires  one  of  the  exclusive 
modifiers  FOR  (a  specified  period  of  time)  or  UNTIL  (a  specified  time)  and 
allows  the  optional  modifiers  AT  WIDTH  (unit  front  in  meters)  -DEPTH  (unit 
depth  in  meters).  For  example: 

PREPARE  UNTIL  031500. 

PREPARE  FOR  12  HOURS  AT  WIDTH  1500  -  DEPTH  500. 

PREPARE  AT  WIDTH  2000  -  DEPTH  775  FOR  1  DAY. 

The  PREPARE  order  causes  the  unit  to  assume  a  defensive  posture  at  its  current 
location.  If  unit  dimensions  are  specified,  these  are  used.  If  unit  dimen¬ 
sions  are  not  specified,  those  loaded  in  the  data  base  for  a  defensive  posture' 
are  used.  This  is  one  of  the  three  orders  under  which  a  unit  may  become 
involved  in  battle  within  the  Ground  Combat  Model  of  the  Period  Processor. 
Rules  for  such  engagement  are  discussed  under  the  ENGAGE  order.  An  artillery 
unit  given  the  PREPARE  order  does  not  enter  the  TACFIRE  Model. 

(d)  LOITER.  The  LOITER  order  requires  the  three  modifiers: 

FOR  (a  specified  period  of  time),  AT  ALTITUDE  (a  specified  altitude  in  feet), 
and  AT  SPEED  (a  specified  flight  speed  in  knots).  For  example: 

LOITER  FOR  15  MIN  AT  ALTITUDE  3000  FT  AT  SPEED  30  KNOTS. 


The  LOITER  order  should  be  given  to  aircraft  units  only.  The  unit  will 
remain  at  its  current  location  and  specified  altitude  for  the  specified  period 
of  time.  Flight  speed  is  used  to  determine  fuel  consumption.  Since  an 
aircraft  unit  under  the  LOITER  order  is  not  vulnerable  to  air  defense,  the 
order  should  only  be  used  for  units  over  friendly  territory.  ^ 

(2)  Move  Activity  Orders.  Move  activity  orders  direct  surface  and 
air  movement.  The  general  requirement  of  these  orders  is  specification  of 
the  route  the  unit  is  to  follow.  The  unit  is  moved  from  its  current  location 
to  each  point  specified  within  the  order  clause  along  a  straight  line.  Class 
I  and  class  III  or  IIIA  are  generally  consumed,  and  ground  units  are  generally* 
vulnerable  to  area  fire  and  aerial  fire.  Vulnerability  of  air  units  depends 
on  the  order.  Other  actions  depend  upon  the  specific  order. 

(a)  MOVE.  The  MOVE  order  is  the  prototype  order  for  ground  % 

movement.  The  modifier  TO  (series  of  X-Y  coordinates)  is  mandatory,  and  the 
modifiers  BY  (travel  mode  mnemonic)  and  PRIORITY  (movement  priority  *  1,2,3, 
or  A)  are  or  clonal.  For  example: 


MOVE  TO  0123000-0096500. 

MOVE  BY  TCCM  TO  0115000-0095750, 

0115000-0098500,  0117500-0100000 
PRIORITY  3. 

MOVE  TO  0116000-0172500  BY  TCCM. 

MOVE  PRIORITY  1  TO  0098000-0118800. 

The  MOVE  order  causes  ground  movement  over  the  specified  route.  Movement 
mode  used  by  the  DIVWAG  Movement  Model  is  as  specified  or,  if  the  BY  modifier 
is  not  present,  cross  country  -deployed  movement  is  assumed.  The  priority 
code,  used  by  the  DIWAG  Engineer  Model  in  allocation  of  engineer  resources 
should  an  obstacle  be  encountered  on  the  move,  is  set  to  4  if  the  PRIORITY 
modifier  is  not  present. 

(b)  WITHDRAW.  The  WITHDRAW  order  uses  the  same  modifier 
structure  as  the  MOVE  order  and,  additionally,  the  optional  AT  WIDTH  (unit 
front  in  meters)  and  -  DEPTH  (unit  depth  in  meters)  modifiers  may  be  used. 

For  example: 

WITHDRAW  TO  0117000-0098000  AT  WIDTH  2000-DEPTH  880. 

WITHDRAW  AT  WIDTH  3000-DEPTH  500  BY  TCCD 
TO  0088000-0115000,0098000-0117000, 

0102500-0118000  PRIORITY  1. 

The  WITHDRAW  order  combines  effects  of  the  MOVE  and  PREPARE  orders.  It 
causes  a  unit  to  assume  a  withdrawal  posture  while  accomplishing  ground 
movement.  This  is  one  of  the  three  orders  under  which  a  unit  may  become 
engaged  in  battle  within  the  DIWAG  Ground  Combat  Model.  Engagement  proce¬ 
dures  are  discussed  under  the  ENGAGE  order. 

(c)  ADVANCE.  Modifier  requirements  of  the  ADVANCE  order  are 
identical  to  those  of  the  WITHDRAW  order  with  the  restriction  that  only  one 
pair  of  coordinates  may  be  specified.  For  example: 

ADVANCE  TO  0101500-0101888. 

ADVANCE  BY  TCCR  AT  WIDTH  1200-DEPTH 

1000  TO  0123400-0090500. 

The  ADVANCE  order  is  the  third  order  under  which  a  unit  may  become  engaged 
in  ground  combat.  The  unit  assumes  an  attacking  posture  and  proceeds  toward 
the  specified  objective  which,  for  proper  ground  combat  engagement,  should 
be  to  the  rear  of  an  opposing  maneuver  unit.  Engagement  procedures  are 
discussed  under  the  ENGAGE  order. 

(d)  FLY.  In  using  the  FLY  order,  the  three  modifiers  OVER 
(series  of  X-Y  coordinates)  AT  SPEED  (air  speed  in  knots)  AT  ALTITUDE'  (altitude 
in  feet)  are  mandatory.  For  example: 

FLY  AT  SPEED  125  AT  ALTITUDE  2500 
OVER  0111000-0088000, 


This  order  is  issued  to  an  air  unit  to  cause  it  to  move  along  a  flight  path 
from  its  present  location  to  a  specified  coordinate  point.  A  list  of 
coordinates  following  the  modifier  OVER  is  used  to  describe  end  points  of  all 
legs  of  the  flight  path.  The  air  unit  will  be  located  (land)  at  the  last 
point  listed.  FLY  orders  should  be  reserved  for  administrative  movement  over 
nonhostile  territory. 

(e)  AIRMOBILE  ASSAULT.  In  writing  this  order  the  modifier  TO 
(series  of  X-Y  coordinates)  is  mandatory,  and  the  modifier  AT  TIME  (specified 
time)  is  optional.  For  example: 

AIRMOBILE  ASSAULT  TO  0111000-0111000,0123000- 

0111000. 

AIRMOBILE  ASSAULT  AT  TIME  030500  TO 
009530-0088000. 

Ihis  order  causes  the  airmobile  assault  segment  of  the  DIVWAG  Airmobile  Model 
to  be  activated.  The  airmobile  task  force  conducts  an  airmobile  movement  'v 
along  the  specified  flight  path.  Initiation  of  movement  is  scheduled  such  . J 
chat  leading  elements  of  the  airmobile  task  force  arrive  at  the  final  coor¬ 
dinate  if  this  is  possible  considering  flight  speeds,  distance,  and  time  the 
order  is  received.  If  the  AT  TIME  modifier  is  not  used,  movement  is  initiated 
when  the  order  is  received.  The  airmobile  task  force  is  vulnerable  to  air 
defense  weapons.  To  properly  execute  the  order,  the  airmobile  task  force 
must  have  previously  received  an  ACCEPT  TRANSPORT  order.  Techniques  for 
inclusion  of  this  order  in  a  Unit  Scenario  are  discussed  in  paragraph  6. 

t 

(f)  RECONNOITER.  In  writing  the  REC0NN0ITER  order,  the  four 
modifiers  BY  (reconnaissance  control  code),  OVER  (series  of  no  more  than 
seven  X-Y  coordinates),  AT  SPEED  (flight  speed  in  knots)  and  AT  ALTITUDE 
(altitude  in  feet)  are  all  mandatory.  For  example: 

RECONNOITER  BY  H322  OVER  0123000-0122000, 

0123000-0117000,  0133000-0117000, 

0133000-0122000  AT  SPEED  50  AT 

ALTITUDE  100.  +i 

Processing  of  the  order  varies  depending  upon  the  nature  of  the  unit  receiving 
the  order  and  the  reconnaissance  control  code. 

JL.  If  the  first  character  of  the  reconnaissance  control  code  • 
is  the  letter  A,  the  unit  receiving  the  order  must  be  an  Air  Force  reconnais¬ 
sance  control  flight.  The  entire  unit  .conducts  the  mission  flying  at  the 
specified  altitude  and  speed  over  the  specified  route.  The  fourth  character 
of  the  reconnaissance  control  code  specifies  the  sensor  load.  Sensors  are 
activated  upon  receipt  of  the  order  and  remain  active  over  the  entire  flight 
path. 

2.  If  the  first  character  of  the  reconnaissance  control  code 
is  the  letter  M,  the  unit  receiving  the  order  must  be  an  army  surveillance 
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aircraft  (Mohawk  type)  flight.  The  entire  unit  conducts  the  flight  as  outlined 
in  the  previous  paragraph.  The  fourth  character  of  the  reconnaissance  control 
code  identifies  the  sensor  package  (which  must  include  the  side  looking  air¬ 
borne  radar  (SLAR)  with  a  ground  terminal) ,  and  the  second  and  third  characters 
control  range,  delay,  and  direction  of  the  SLAR. 

.3.  If  the  first  character  of  the  reconnaissance  control  code 
is  the  letter  H  or  F,  the  unit  receiving  the  order  must  be  an  army  unit 
containing  light  observation  helicopters  (H)  or  light  fixed  wing  scout  air¬ 
craft  (F) .  In  response  to  the  order,  a  mission  unit  is  created  to  conduct 
the  mission.  The  mission  unit  flies  to  the  first  coordinate,  at  which  point 
target  sensing  may  commence.  Upon  completion  of  the  mission,  the  mission 
unit  returns  to  the  unit  which  received  the  order.  The  mission  unit  may 
conduct  a  route  or  an  area  reconnaissance,  as  determined  by  the  control  code 
and  discussed  in  paragraph  6. 

A_.  In  all  cases,  the  RECONNOITER  order  provides  the  ability 
to  control  airborne  sensors.  Aircraft  responding  to  a  RECONNOITER  order  are 
vulnerable  to  air  defense  weapons. 

(3)  Engagement  Orders.  The  group  of  engagement  orders  permit  the 
game  staff  to  control  application  of  firepower  within  the  Period  Processor. 

The  FIRE  order  controls  both  the  Area  Fire  and  Nuclear  Assessment  Models;  the 
ENGAGE  order  controls  the  Ground  Combat  Model;  the  MISSION  IS  order  controls 
the  Air  Ground  Engagement  Model.  It  is  axiomatic  that  these  orders  be  given 
only  to  appropriate  units.  FIRE  orders  should  be  given  only  to  units  capable 
of  delivering  conventional  or  nuclear  indirect  fires.  ENGAGE  orders  should 
be  given  only  to  maneuver  units  capable  of  engagement  within  the  Ground  Combat 
Model.  MISSION  IS  orders  should  be  given  only  to  units  capable  of  carrying 
out  a  close  air  support  mission  either  with  attack  helicopters  of  tactical 
Air  Force  aircraft. 

(a)  FIRE.  The  FIRE  order  activates  the  Area  Fire  or  Nuclear 
Assessment  Model.  It  should,  of  course,  appear  within  the  Unit  Scenario  of 
a  unit  that  is  capable  of  carrying  out  the  fire  mission.  The  FIRE  order 
structure  depends  upon  whether  a  conventional  or  nuclear  fire  is  required. 

1^.  For  conventional  fires  the  FIRE  order  must  contain  the 
mandatory  modifiers  ON  (coordinates  of  target)  and  MUNITION  TYPE  (Area  Fire 
munition  code  beginning  with  A)  and  one  of  the  exclusive  modifiers,  NUMBER  OF 
ROUNDS  (a  number),  NUMBER  OF  VOLLEYS  (a  number),  or  IMPACT  RADIUS  (a  number). 
For  example : 

FIRE  ON  0123000-0098500  NUMBER  OF  ROUNDS 
25  MUNITION  TYPE  A013  IMPACT 
RADIUS  100. 

The  unit  receiving  the  order  will  fire  the  specified  number  of  rounds  or 
volleys  of  the  type  specified  upon  the  specified  location. 
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2.  For  nuclear  fires,  four  modifiers  should  be  viewed  as 
mandatory.  These  are. ON  (desired  ground  zero),  MUNITION  TYPE  (munition  code 
starting  with  N  or  D) ,  NUMBER  OF  ROUNDS  1,  and  HEIGHT  OF  BURST  (preset  height 
of  burst  option  index).  IMPACT  RADIUS  (desired  height  of  burst  if  not  preset) 
is  required  if  HEIGHT  OF  BURST  is  not  preset.  The  desired  ground  zero  is 
specified  in  terms  of  one  X-Y  coordinate  pair.  The  munition  code  is  a  four- 
character  alphanumeric  code  wherein  the  first  character  must  be  N  or  D  and  the' 
remaining  characters  relate  to  the  Nuclear  Assessment  Model  constant  data  base, 
allowing  specification  of  a  firing  weapon,  a  munition,  a  fuzing  option,  and 
a  yield.  Specification  of  a  height  of  burst  depends  upon  whether  the  specified 
fuze  allows  free  selection  of  height  of  burst  or  only  preset  height  options. 

If  preset  options  are  used,  the  modifier  HEIGHT  OF.  BURST  is  followed  by  a 
height  index  (1,  2,  3,  4).  If  free  selection  of  a  height  of  burst  is  possible, 
the  HEIGHT  OF  BURST  is  followed  by  the  number  zero;  and  IMPACT  RADIUS,  by 
desired  height  in  meters.  Examples: 

FIRE  ON  0127000-0115000  NUMBER  OF  ROUNDS  1 
MUNITION  TYPE  NA33  HEIGHT  OF  BURST  2 
IMPACT  RADIUS  100. 

FIRE  ON  0127000-0115000  NUMBER  OF  ROUNDS  1 
MUNITION  TYPE  NXA2  HEIGHT  OF  BURST  1 
IMPACT  RADIUS  500. 

(b)  ENGAGE.  The  ENGAGE  order  has  one  mandatory  modifier,  IN 
BATTLE  (battle  name),  and  is  always  used  in  conjunction  with  the  ADVANCE  order 
For  example: 

ADVANCE  TO  0123100-0125000. 

ENGAGE  IN  BATTLE  BRAVO. 

The  combination  of  an  ADVANCE  order  followed  by  an  ENGAGE  order  is  used  to 
initiate  a  battle  within  the  DIVWAG  Ground  Combat  Model,  Each  time  an  ADVANCE 
order  is  encountered  within  a  Unit  Scenario,  the  next  command  is  checked  for 
an  ENGAGE  order.  If  the  ENGAGE  order  is  not  found,  the  ADVANCE  is  executed  r' 

as  a  simple  movement  event.  If  an  ENGAGE  order  is  found,  the  following 
sequence  of  events  takes  place: 

1,  The  list  of  units  involved  in  the  battle  named  in  the 
ENGAGE  order  is  obtained  from  the  battle  declaration  statement  of  the  appro¬ 
priate  Battle  Paragraph. 

,2.  From  the  list  of  all  units  involved  in  the  battle,  those 
units  which  are  on  the  opposing  side  of  the  unit  in  whose  scenario  the  ENGAGE 
order  appears  and  whose  current  order  is  either  PREPARE  or  WITHDRAW  are 
selected.  These  units  constitute  potential  opponents. 

3,,  The  list  of  potential  opponents  is  checked  for  proximity 
to  the  advancing  unit.  If  no  potential  opponents  are  within  3000  meters 
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(front-to-front)  of  the  advancing  unit,  the  battle  is  not  initiated.  (The 
process  will  be  repeated  as  each  Movement  Model  increment  generated  by  the 
ADVANCE  order  is  initiated.) 

If  a  potential  opponent  is  within  3000  meters  of  the 
advancing  unit,  the  battle  is  initiated  by  scheduling  the  first  Ground  Combat 
Model  increment.  The  increment  is  scheduled  to  take  place  after  the  standard 
Ground  Combat  Model  increment  length  (15  minutes)  has  elapsed. 

_5.-  At  the  scheduled  time,  any  unit  listed  in  the  Battle 
Paragraph  which  has  an  ADVANCE,  PREPARE,  or  WITHDRAW  order  (a  combat  enabling 
order)  will  engage  all  units  of  the  opposing  force,  also  listed  in  the  Battle 
Paragraph,  and  also  having  a  combat  enabling  order  and  within  3000  meters, 

6.  The  force  to  which  the  unit  that  had  the  initiating 
ENGAGE  order  belongs  is  treated  as  the  attacking  force  within  the  Ground 
Combat  Model. 

(c)  MISSION  IS.  The  MISSION  IS  order  is  used  to  control  the 
Air  Ground  Engagement  Model.  The  order  clause  must  contain  the  three  mandatory 
modifiers  TARGET  NUMBER  (a  target  intelligence  index  code  from  a  DIVWAG 
intelligence  report),  NUMBER  OF  AIRCRAFT  (a  specified  number),  and  AIRCRAFT 
TYPE  (a  specified  equipment  item  code)  and  may  contain  the  optional  modifier 
AT  TIME  (a  specified  time).  For  example: 

MISSION  IS  TARGET  NUMBER  480001  AIRCRAFT  TYPE  87 
NUMBER  OF  AIRCRAFT  4  AT  TIME  030720. 

This  order  must  be  within  the  Unit  Scenario  of  a  unit  that  is  capable  of 
aerial  attack  of  a  target.  Upon  receipt  of  the  order  a  mission  unit  is  formed 
from  the  unit  receiving  the  order,  where  composition  of  the  mission  unit  is 
as  specified  in  the  order;  and  the  Air  Ground  Engagement  Model  simulation  of 
the  mission  unit  strike  against  the  specified  target  is  scheduled.  If  a  time 
is  specified,  and  it  is  possible  to  strike  the  target  at  the  specified  time, 
the  Air  Ground  Engagement  Model  events  are  scheduled  accordingly.  If  a  time 
is  not  specified  or  is  specified  but  unattainable,  scheduling  of  the  first 
portion  of  the  model  takes  place  at  once;  and  the  strike  will  occur  after 
appropriate  delays  within  the  model  data  base  have  passed.  To  function 
properly,  the  unit  must  have  the  specified  number  and  type  of  aircraft  avail¬ 
able  (except  if  an  Air  Force  unit  and  the  aircraft  is  an  appropriate  TACAIR 
item).  This  may  be  ensured  by  use  of  the  RETAIN  order,  discussed  in  e  ub- 
sequent  paragraph. 

(4)  Engineer  Activity  Orders.  The  DIVWAG  Engineer  Model  functions 
as  a  resource  allocation  filter,  controlling  the  assignment  of  engineer 
•esources  to  tasks  that  must  be  accomplished.  In  consonance  with  this  approach, 
SL  orders  controlling  engineer  activity  are  task  oriented  rather  than  unit 
oriented.  For  a  given  game  period,  all  commands  requesting  engineer  tasks 
are  consolidated  within  one  Unit  Scenario  for  each  force,  and  the  scenarios 


B-13 


given  the  unit  identification  BLUEFORC  or  REDFORCE  as  appropriate.  Three 
basic  DSL  orders  are  used  to  initiate  engineer  activity,  and  one  DSL  order 
stops  activity  on  a  given  task. 

Activity  Initiation  Syntax.  The  basic  DSL  orders  to 
initiate  engineer  activity  are  BUILD,  BREACH,  and  REMOVE.  Order  clauses  are 
built  around  these  basic  orders  identically.  The  order  clause  contains  the 
basic  order;  one  of  the  exclusive  modifiers  BARRIER  or  BRIDGE  or  FACILITY, 
followed  by  a  barrier  facility  identification;  one  of  the  exclusive  modifiers 
BEGIN  BY  or  COMPLETE  BY,  followed  by  a  specified  time;  optionally,  the  modi¬ 
fier  PRIORITY  followed  by  a  priority  indicator  1,  2,  3  or  4;  optionally,  one 
of  the  modifiers  MANDATORY  or  DESIRED.  Several  examples  follow: 

BUILD  BARRIER  MNA007  BEGIN  BY  010800. 

REMOVE  BARRIER  MNA028  MANDATORY 
COMPLETE  BY  020705. 

BREACH  MANDATORY  PRIORITY  1  COMPLETE  BY 
010715  BARRIER  MNT001. 

BUILD  BRIDGE  BRF011  BEGIN  BY  022200 
DESIRED. 

REMOVE  FACILITY  BFL003  BEGIN  BY  041730 
PRIORITY  3. 

2_.  Activity  Initiation  Response.  The  BUILD.  function  is 
defined  as  construction  of  a  new  barrier  or  facility  or  repair  and  rebuilding 
of  one  that  has  been  breached.  The  BREACH  function  is  the  disruption  of  the 
functional  purpose  of  the  obstacle  or  facility,  while  the  REMOVE  function  is 
total  destruction  or  dismantling  and  removal  for  use  elsewhere.  The  modifier^ 
BRIDGE  and  FACILITY  are  interchangeable.  The  Engineer  Model  operates  upon 
a  group  of  tasks,  assigning  resources  to  complete  or  initiate  tasks  as  closely 
to  the  times  requested  as  is  possible.  The  user  should  be  familiar  with  the 
priority  algorithms  used  by  the  Engineer  Model  when  assigning  the  optional 
modifiers.  Briefly,  all  task  orders  having  the  modifier  MANDATORY  will  have 
preference  before  task  orders  having  the  modifier  DESIRED.  If  neither  of  the 
modifiers  is  used,  the  task  order  is  treated  as  if  the  DESIRED  modifier  were 
present.  The  PRIORITY  modifier  and  its  data  are  used  as  a  tie-breaker  betweer 
task  orders  otherwise  identical.  If  the  modifier  is  not  used,  the  task  order 
is  treated  as  though  the  modifier  PRIORITY  4  had  been  present. 

.3.  Relation  to  Automatic  Task  Requests.  The  DIVWAG  Movement 
Model  will  generate  automatic  requests  when  a  moving  unit  encounters  an 
obstacle.  The  order  will  be  to  BREACH  if  the  obstacle  is  breachable  or  to 
BUILD  a  facility  if  the  obstacle  is  a  natural  obstacle.  An  automatic  order 
will  always  be  treated  as  having  the  modifier  MANDATORY,  the  modifier  BEGIN 
BY  (time  the  obstacle  is  encountered),  and  PRIORITY  (the  priority  associated 
with  the  movement  event), 

4,  Task  Cessation.  Any  engineer  activity  may  be  halted  by 
the  DSL  order  STOP  TASK  (barrier/facility  identification).  For  example* 

STOP  TASK  MNA013. 
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Work  on  the  specified  task  halts  at  once,  and  any  resources  committed  to  the 
task  are  available  for  reassignment. 

(5)  Transfer  Orders.  The  set  of  transfer  activity  orders  provide  a 
means  for  various  administrative  and  organizational  controls  to  be  implemented 
within  the  model. 

(a)  JOIN.  The  JOIN  order  has  one  mandatory  modifier  UNIT  (a  UID) 

For  example: 

JOIN  UNIT  R1122333. 

Receipt  of  this  order  causes  the  unit  so  ordered  to  integrate  into  another 
organization.  The  unit  is  completely  absorbed  by  the  receiving  unit,  its 
strength  being  reflected  by  the  receiving  unit  in  any  subsequent  actions. 

Once  a  unit  joins  another  unit,  it  can  accept  no  more  orders  until  it  has 
been  detached.  This  order  is  used  to  change  task  organizations  and,  con¬ 
currently,  results  in  the  detail  of  resolution  being  reduced  as  several  units 
join  into  one  superior.  If  the  receiving  unit  (unit  being  joined)  had  been 
a  nonresolution  unit  prior  to  execution  of  the  order  it  assumes  the  location 
of  the  joining  unit  and,  if  a  Unit  Scenario  is  provided,  will  immediately 
execute  the  first  command  of  its  Unit  Scenario. 

(b)  DETACH.  The  DETACH  order  requires  the  mandatory  modifier 
UNIT  (a  UID)  and  may  have  the  optional  modifier  TYPE  (a  UTD) .  For  example: 

DETACH  UNIT  R1122BAR. 

DETACH  UNIT  B113MECH  TYPE  GRMI. 

The  DETACH  order  causes  the  named  subunit  to  be  broken  out  of  the  superior 
unit  receiving  the  order  (e.g.,  one  company  out  of  a  battalion).  Without  the 
optional  modifier,  TYPE,  the  detached  unit  is  formed  with  its  pro  rata  share 
of  the  superior  unit's  strength  (personnel  and  equipment).  When  the  optional 
modifier,  TYPE,  is  used,  the  detached  unit  will  be  broken  out  at  its  full 
authorized  strength,  to  the  extent  that  the  strength  of  the  superior  unit 
allows.  The  detached  unit  is  initially  given  the  same  location  as  the  unit 
from  which  it  was  detached  and  will  immediately  begin  to  follow  any  DSL  orders 
provided  for  it  within  a  Unit  Scenario.  The  detaching,  or  superior,  unit 
will  maintain  all  residual  strength,  if  any,  and  will  continue  to  follow 
DSL  orders  as  long  as  it  has  residual  strength.  Combined  use  of  the  DETACH 
and  JOIN  orders  provides  the  ability  to  restructure  organizations  in  any 
manner  desired,  limited  only  by  the  quantity  and  definition  of  units  within 
the  game.  Used  in  isolation,  the  DETACH  order  results  in  an  increase  in  the 
detail  of  unit  resolution.  Proper  functioning  of  the  order  requires  that  the 
unit  being  detached  is  already  defined  to.  the  game,  insofar  that  it  must  have 
been  defined  as  a  subordinate  of  the  unit  from  which  detached  either  within 
the  task  organization  at  the  start  of  the  game  or  through  a  previous  JOIN 
order.  The  DETACH  order  with  optional  TYPE  modifier  may  also  be  used  to 
introduce  new  units  to  the  game  if,  within  the  original  task  organization, 
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the  unit  receiving  the  DETACH  order  was  defined  as  being  of  a  nonbasic  UTD 
and  having  no  subordinates.  In  this  case  the  UTD  of  the  superior  unit  must 
be  defined  within  TOE  data  as  containing  the  UTD  of  the  unit  specified  in  the 
DETACH  order . 

(c)  ASSUME  CONTROL  OF.  This  order,  followed  by  the  modifier, 
UNIT,  causes  the  named  unit  to  come  under  control  of  the  unit  receiving  the 
order.  Upon  implementation  of  the  order,  status  reports  for  the  assuming 
unit  will  reflect  strengths  of  the  new  subordinate.  If  the  named  unit  is 
not  already  under  control  of  the  assuming  unit  and  is  not  a  resolution  unit, 
it  will  be  detached  from  its  superior  upon  execution  of  the  order.  Example: 

ASSUME  CONTROL  OF  UNIT  B1212123. 

(d)  ASSIGNMENT  IS.  This  order,  followed  by  an  exclusive 
modifier,  DIRECT  SUPPORT  OF  UNIT,  REINFORCING  UNIT,  GENERAL  SUPPORT,  or 
GENERAL  SUPPORT-REINFORCING  UNIT,  causes  the  unit  receiving  the  order  to  have 
the  designated  assignment  for  allocation  of  its  supporting  resources.  Applic 
tions  are  within  the  TACFIRE  Model,  where  fire  support  is  allocated  per 
assignment;  within  the  Air  Ground  Engagement  Model,  where  aerial  fire  support 
may  be  allocated  by  assignment;  within  the  Airmobile  Model,  where  allocation 
of  lift  and  escort  aircraft  is  per  assignment;  and  in  the  Engineer  Model, 
where  allocation  of  engineer  resources  may  be  per  assignment.  Only  the 
DIRECT  SUPPORT  assignment  is  actually  acted  upon  within  the  Period  Processor, 
the  other  assignments  simply  provide  the  user  means  of  documenting  organiza¬ 
tional  features  of  the  force.  In  all  cases,  the  GENERAL  SUPPORT  assignment 
serves  to  cancel  previous  assignments.  Examples: 

ASSIGNMENT  IS  GENERAL  SUPPORT. 

ASSIGNMENT  IS  DIRECT  SUPPORT  OF  UNIT  Blllllll. 

ASSIGNMENT  IS  REINFORCING  UNIT  B1234567. 

ASSIGNMENT  IS  GENERAL  SUPPORT- REINFORCING 
UNIT  B1212123. 

(e)  ACCEPT  TRANSPORT.  This  order  initiates  the  first  segment  of 
the  Airmobile  Model,  which  allocates  aircraft  and  moves  the  aircraft  to  the 
location  of  the  airmobile  task  force  to  be  lifted.  The  ACCEPT  TRANSPORT 
order  must  appear  in  the  Unit  Scenario  of  the  unit  being  lifted  and  must 
precede  the  AIRMOBILE  ASSAULT  order  for  which  aircraft  are  being  allocated. 
The  MIX  modifier  identifies  the  type  lift  and  escort  aircraft  to  be  used  and 
a  standard  lift  to  escort  ratio.  (This  ratio  is  overridden  by  use  of  the 
NUMBER  OF  ESCORTS  modifier.)  The  Airmobile  Model  allocates  the  specified 
number  of  lift  aircraft,  if  the  NUMBER  OF  AIRCRAFT  modifier  is  used,  or 
sufficient  aircraft  to  move  the  entire  unit  in  the  specified  number  of  trips, 
if  the  NUMBER  OF  TRIPS  modifier  is  used.  If  the  AT  TIME  modifier  is  used, 
aircraft  are  scheduled  to  arrive  at  the  location  of  the  unit  to  be  lifted 

at  the  specified  time.  If  such  a  time  is  not  specified  aircraft  arrive  as 
soon  as  possible  after  receipt  of  the  order. 
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(f)  RELEASE  TRANSPORT.  This  order  requires  no  modifiers  or 
data.  For  example: 

RELEASE  TRANSPORT. 

The  RELEASE  TRANSPORT  order  may  appear  in  the  Unit  Scenario  of  an  airmobile 
task  force.  If  it  appears  it  must  not  precede  the  AIRMOBILE  ASSAULT  order. 

In  response  to  the  RELEASE  TRANSPORT  order,  all  aircraft  are  returned  to 
their  home  bases  upon  completion  of  the  airmobile  movement  or  upon  receipt 
of  the  order,  whichever  occurs  later.  If  the  order  is  not  used,  aircraft 
remain  with  the  airmobile  task  force. 

(g)  RETAIN.  The  RETAIN  order  has  two  mandatory  modifiers: 

NUMBER  OF  AIRCRAFT  (a  specified  number)  and  AIRCRAFT  TYPE  (an  equipment  item 
code) .  For  example: 

RETAIN  AIRCRAFT  TYPE  188  NUMBER  OF  AIRCRAFT  8. 

This  order  should  be  reserved  for  use  in  the  Unit  Scenario  of  a  unit  which 
is  capable  of  flying  attack  helicopter  strikes  within  the  Air  Ground  Engage¬ 
ment  Model.  When  the  order  is  used,  the  specified  type  and  number  of  aircraft 
are  exempt  from  automatic  scheduling  by  the  Air  Ground  Engagement  Model.  The 
order  is  intended  to  be  used  in  conjunction  with  the  MISSION  IS  order,  to 
ensure  availability  of  sufficient  aircraft  to  conduct  strikes  ordered  by  the 
game  staff.  Aircraft  are  released  for  automatic  scheduling  as  they  return 
from  a  DSL  ordered  strike.  Aircraft  may  also  be  released  for  automatic 
scheduling  by  a  new  RETAIN  order,  where  the  specified  number  is  less  than  the 
number  of  aircraft  currently  retained.  For  example: 

RETAIN  AIRCRAFT  TYPE  188  NUMBER  OF  AIRCRAFT  0. 

(6)  Pseudo  Orders.  Two  DSL  pseudo  orders  can  be  used  in  the  con¬ 
struction  of  Unit  Scenarios.  The  orders  are  so  called  because  they  differ 
from  those  described  above  with  respect  to  their  reasons  for  existence.  They 
are  not  used  to  direct  units  to  perform  military  activities  but  rather  are 
inserted  into  Unit  Scenarios  to  perform  the  functions  described  below. 

(a)  GO  TO.  The  GO  TO  order  is  used  to  direct  a  unit  to  follow 
a  set  of  orders  in  a  particular  sequence  or  with  particular  exceptions, 
depending  on  the  order  string  structure  and  satisfaction  of  conditional 
statements.  A  GO  TO  order  must  be  followed  by  a  statement  label.  For  example, 
the  statement  GO  TO  6  ifiay  be  inserted  ir.  an  order  string  to  direct  the  unit 

to  start  executing  a  statement  labeled  6  immediately.  Statement  6  may  follow 
several  others  in  the  order  string.  If  so,  the  orders  between  the  statement 
GO  TO  6  and  statement  6  will  be  ignored  by  the  unit. 

(b)  TERMINATE.  This  order,  when  encountered  in  any  unit’s 
scenario,  will  cause  all  simulation  to  halt  and  terminate  the  period.  It  is 
most  useful  in  those  cases  where  important  or  critical  situations  are  expected 
to  occur  and  for  which  contingency  planning  is  not  feasible  or  particularly 
desirable.  The  TERMINATE  order  should  be  used  sparingly  and  with  caution 
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because  it  will  halt  all  processing.  To  continue  the  war  game  a  new  game 
period,  with  complete  DSL  instructions  for  all  units,  must  be  prepared. 

(7)  Scatterable  Mine  Order.  The  emplacement  of  scatterable  mines 
by  indirect  fire  or  aerial  delivery  means  is  directed  by  the  EMPLACE  order. 
This  order  is  limited  to  field  emplacement  by  indirect  fire  or  aerial  means 
The  emplacement  of  scatterable  minefields  by  more  conventional  ground  means 
is  treated  through  the  Engineer  BUILD  order  described  in  paragraph  3b (4) 
above . 


(a)  System.  The  EMPLACE  order  must  be  followed  by  the  manda¬ 
tory  modifiers  FIELD  (followed  by  a  6-character  minefield  identifier)  and 
MUNITION  TYPE  (followed  by  a  4-character  munition  code).  Additionally, 
one  of  the  exclusive  modifiers  NUMBER  OF  ROUNDS,  NUMBER  OF  VOLLEYS,  or 
NUMBER  OF  TRIPS  (followed  by  an  integer  number)  must  be  used. 

(b)  Emplacement  by  Indirect  Fire.  Emplacement  of  minefields 
by  indirect  fire  can  be  accomplished  by,  and  the  order  may  be  given  to, 
only  artillery  firing  units.  Such  units  are  identified  within  the  model 
as  units  which  have  the  letters  FA  in  the  third  and  fourth  characters  of 
the  Unit  Type  Designators.  For  example,  units  with  the  following  UTD 
would  accept  the  EMPLACE  order  for  indirect  fire  minefield  delivery: 

GFFA,  MBFA,  NSFA,  etc. 

1.  The  field  to  be  emplaced  is  identified  by  the  modifier 
FIELD  (field  Tdentif lcation  where  the  field  identification  is  a  six- 
character  mnemonic.  The  first  three  characters  must  be  MVA,  MNP,  MNT, 
or  MNS  and  the  last  three  characters  must  be  integers  in  a  range  depending 
on  the  first  three: 

MNA001  -  MNA500 

MNP001  -  MNP 150 

MNT001  -  MNT150 

MNS001  -  MNS500 

2^.  The  munition  mnemonic  must  be  of  the  form  AOnn  where 
nn  ranges  from  01  to  36;  this  should  be  the  code  of  a  weapons/munition 
mix  loaded  for  minefield  delivery  within  the  Area  Fire  Model  data  load. 

3.  In  response  to  the  EMPLACE  order,  the  ordered  unit  will 
fire  the  designated  number  of  rounds  or  volleys  of  the  designated  type 
into  the  area  of  the  specified  minefield.  Delivery  is  dependent  on  the 
field  being  within  the  range  capabilities  of  the  specific/munition  com¬ 
bination.  Should  the  firing  unit  have  fewer  than  the  desired  number  of 
rounds,  all  munition  available  to  the  unit  will  be  fired. 
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(c)  Emplacement  by  Aerial  Means.  Aerial  emplacement  can  only 
be  accomplished  by  an  aerial-type  unit;  that  is,  by  a  unit  having  a  UTD 
which  ends  with  the  character  H  or  Y.  The  same  restrictions  on  the  mine¬ 
field  name  as  were  presented  for  indirect  fire  delivery  apply. 

1.  For  aerial  emplacement,  the  MUNITION  TYPE  modifier  must 
be  followed  by  a  7-character  aerial  emplacement  code. 

a_.  First  character  of  the  aerial  emplacement  code 
must  be  A,  C,  or  H,  designating  emplacement  by  high  performance  (A),  fixed 
wing  cargo  type  (C) ,  or  helicopter  (H) .  If  helicopter  delivery,  the  UTD 
of  the  unit  receiving  the  order  must  end  with  H;  otherwise,  the  UTD  of  the 
ordered  unit  must  end  with  Y. 

_b.  Second  character  of  the  aerial  emplacement  code 
must  be  an  integer  0,  1,  or  2.  This  specifies  mission  abort  criterion: 

0»do  not  abort  in  any  case;  1-abort  if  aircraft  fired  upon;  2-abort  if 
aircraft  losses  are  experienced. 

c.  Third  character  of  the  aerial  emplacement  code 
is  an  integer  in  the  range  1-9.  This  specifies  an  index  for  mean  height 
at  the  dispensing  site,  where  the  height  values  are  loaded  in  constant  data 
base. 


£.  Fourth  character  of  the  emplacement  code  is  an 
integer  1-9.  This  specifies  an  aircraft  mix  table  (type  and  number  of 
mines  and  type  of  aircraft)  to  be  used  in  emplacement.  The  mix  tables 
are  part  of  the  model's  constant  data  load. 

2.  In  response  to  the  order,  the  number  of  aircraft 
specified  in  NUMBER  OF  TRIPS  of  the  type  in  the  appropriate  mix  table 
will  be  given  full  loads,  as  specified  in  the  mix  table,  and  will  be 
sent  to  emplace  the  named  field  as  a  single  mission  unit. 
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c.  DSL  Order  Modifiers  and  Data  Elements.  Most  of  the  DSL  order  mod¬ 
ifiers  and  some  basic  DSL  orders  require  data  elements  to  complete  an  order 
clause.  The  required  format  of  a  data  element  depends  on  the  order  or  order 
modifier  with  which  it  is  associated.  This  paragraph  discusses  the  order 
modifiers  and  all  required  data  elements. 

(1)  There  are  two  basic  rules  regulating  the  entry  of  data  elements 
when  required  by  an  order  or  an  order  modifier: 

(a)  A  data  element  must  follow  the  order  or  order  modifier  with  which 
it  is  associated.  In  the  following  examples  data  elements  are  underlined: 

FLY  AT  SPEED  150  KNOTS  AT  ALTITUDE  3000  FEET 
OVER  0112000-0098500,0115000-0127500. 

ADVANCE  TO  0113000-0127000  BY  TCCD 

AT  WIDTH  2000M-DEPTH  1500M  PRIORITY  1. 

(b)  Units  of  measure  may  be  used  as  parts  of  data  elements  to  provide 
clarification;  however,  the  system  requires  that  each  type  of  data  be  input 
in  a  specific  unit  of  measure.  For  example,  aircraft  speed  must  be  in  knots, 
and  aircraft  altitude  must  be  in  feet.  Only  units  of  time  measure  are 
actually  recognized  as  key  words  by  the  compiler.  Periods  must  not  be  used 

to  terminate  abbreviations;  they  are  used  exclusively  to  terminate  statements. 
If  units  of  measure  are  used  in  DSL  statements,  they  must  be  restricted  to 
the  following  forms: 

.  DAY,  DAYS,  DA,  or  DAS 

.  HOUR,  HOURS  HR,  or  HRS 

.  MINUTE,  MINUTES,  MIN,  or  MINS 

.  FEET  or  FT 

.  METER,  METERS,  or  M 

.  KNOT  or  KNOTS. 

(2)  Format  of  data  elements  generally  must  follow  a  rigid  pattern.  An 
exception  is  the  specification  of  a  time  or  a  period  of  time.  Times  may  be 
expressed  either  by  a  six-digit  date  time  group  or  in  clear  text.  In  either 
case  interpretation  of  the  data  element  as  a  specific  time  or  as  a  period 

of  time  depends  on  the  modifier  with  which  it  is  used. 


(a)  The  first  form  uses  an  integer  number  of  six  digits  with  the 
digits  in  three  blocks  of  two  digits  each.  The  blocks  are  in  fixed  order. 

The  leftmost  block  represents  the  number  of  days,  the  center  block  the  number 
of  hours,  and  the  rightmost  block  the  number  of  minutes.  If  fewer  than  six 
digits  are  used,  a  zero  fill  on  the  left  is  assumed.  Examples: 

112233  (denoting  11  days,  22  hours,  and  33  minutes) 

1122  (read  as  001122  with  zero  fill  on  the  left, 

denoting  11  hours  and  22  minutes) 

0800  (read  as  000800,  denoting  8  hours) 

126  (read  as  000126,  denoting  1  hour  and 

26  minutes) . 

(b)  The  second  form  uses  integer  numbers  of  days,  hours,  and 
minutes,  each  of  which  must  be  followed  by  the  word  DAY,  HOUR,  or  MINUTE 

(or  abbreviations  thereof  as  listed  above).  The  words  DAY,  HOUR,  and  MINUTE 
(or  abbreviations)  are  recognized  by  the  compiler;  therefore,  the  data  may  be 
written  in  any  order  and  with  any  omissions.  Examples: 

1  DAY  12  HOURS  10  MINUTES 

12  HOURS  10  MINUTES  1  DAY 

12  HR  10  MIN 

120  MIN 

2  HRS 

(3)  For  those  orders  and  order  modifiers  that  require  data  elements, 
specific  data  formats  have  been  established.  All  order  modifiers  and  those 
basic  orders  requiring  data  elements  are  presented  below  in  alphabetical  order. 

(a)  AIRCRAFT  TYPE  (equipment  item  code).  The  data  element  is  an 
integer  between  1  and  200  denoting  the  equipment  item  code  of  aircraft. 
Example: 


AIRCRAFT  TYPE  188 

(b)  AT  ALTITUDE  (height  of  aircraft  in  feet).  The  data  element 
is  an  integer.  Example: 

AT  ALTITUDE  6000  FT 
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(c)  AT  SPEED  (velocity  of  aircraft  in  knots).  The  data  element 
is  an  integer.  Example: 

AT  SPEED  375 

(d)  AT  TIME  (a  specified  time).  The  data  element  is  a  time  group 
as  described  above.  Examples: 

AT  TIME  011230 

AT  TIME  1  DAY  12  HR  30  MIN 

(e)  AT  WIDTH  (unit  frontage  in  meters) .  The  data  element  is 
an  integer  value  used  in  conjunction  with-DEPTH.  Example: 

AT  WIDTH  2000M  -DEPTH  1200M 

(f)  BARRIER  (barrier  identification  code).  The  data  element  is 
a  six-character  mnemonic,  the  first  three  characters  being  alphabetic  and  the 
last  three  characters  numeric.  Example: 

BARRIER  MNA013 

(g)  BEGIN  BY  (a  specified  time).  The  data  element  is  a  time 
group  as  described  above.  Examples: 

BEGIN  BY  010800 

BEGIN  BY  8  HOURS  1  DAY 

(h)  BRIDGE  (facility  identification  code) .  The  data  element  is  a' 
six-character  mnemonic,  the  first  three  characters  being  alphabetic  and  the 
last  three  numeric.  Example: 

BRIDGE  BFX103 

(1)  BY  (code).  Two  cases  exist: 

1^.  BY  (movement  mode  mnemonic).  The  data  element  consists 
of  four  alphabetic  characters,  comprising  a  movement  mode  mnemonic  for  the 
Movement  Model.  See  Figure  B-l.  Example: 

BY  TCCD 


_2 .  BY  (reconnaissance  control  code) .  The  data  element 
consists  of  four  alphanumeric  characters,  the  first  of  which  is  A,  M,  F  or  H, 
comprising  a  control  code  for  the  Reconnaissance  Overlay.  Example: 

BY  AXX3 
BY  MAL6 
BY  HR36 
BY  HA 25 
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Travel  Mode 

Definition 

Description 

Movement  type 

A 

Administrative 

Movement  of  units  by  road  nets. 

Uses  the  most  efficient  trans¬ 
portation  systems  available. 

B 

Tactical 

Movement  as  part  of  an  attack, 
withdrawal,  or  other  tactical 
plan  external  to  movement  within 
Ground  Combat  engagements. 

Route  type 

CC 

Cross  country 

Route  is  subject  to  natural 
terrain  conditions. 

RA 

Paved  roads 

Route  is  such  that  road  beds  are 
asphalt  or  concrete  with  at  least 
two  lanes  with  good  shoulders. 

RG 

Gravel  roads 

Route  is  gravel  or  similar 
surfaced  road. 

RD 

Dirt  roads 

Route  is  dirt,  road  is  narrow 
and/or  marginally  maintained. 

Formation 

M 

Column  march 

Unit  is  in  a  column  formation. 

R 

Reconnaissance. 

Unit  on  a  ground  reconnaissance 
type  mission. 

D 

Deployed . 

Unit  is  partially  deployed  in 
anticipation  of  imminent  contact 
with  the  enemy. 

Recognized  movement  combinations 


ARAD 

ARDD 

ARGD 

TRAD 

TRDD 

TRGD 

TCCD 

ARAM 

ARDM 

ARGM 

TRAM 

TRDM 

TRGM 

TCCM 

ARAR 

ARDR 

ARGR 

TRAR 

TRDR 

TRGR 

TCCR 

Figure  B-l.  Travel  Mode  Mnemonic  Descriptions 
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(j)  COMPLETE  BY  (a  specified  time).  The  data  element  is  a  time 
group  a9  described  above.  Examples: 

COMPLETE  BY  031720 

COMPLETE  BY  3  DAYS  17  HR  20  MIN 

(k)  -DEPTH  (unit  depth  in  meters) .  The  data  element  is  an 
integer  value  used  in  conjunction  with  AT  WIDTH.  Example: 

AT  WIDTH  1250  -DEPTH  1525 

(l)  DESIRED.  No  data  element. 

(m)  DIRECT  SUPPORT  .OF  UNIT  (UID  of  supported  unit) .  The  data 
element  is  an  eight-character  alphanumeric  unit  identification  beginning  with 
B  or  R.  Example: 

DIRECT  SUPPORT  OF  UNIT  B1212AAR 

(n)  FACILITY  (facility  identification  code).  The  data  element 
is  a  six-character  mnemonic,  the  first  three  characters  being  alphabetic  and 
the  last  three  numeric.  Example: 

FACILITY  BFX103 

(o)  FOR  (a  specified  period  of  time).  The  data  element  is  a 
time  group  as  defined  above.  The  following  examples  are  equivalent: 

FOR  200 

FOR  2  HOURS 

FOR  120  MIN 

(p)  GENERAL  SUPPORT.  No  data  required. 

(q)  GENERAL  SUPPORT-REINFORCING  UNIT  (UID  of  the  reinforced  unit) 
The  data  element  is  an  eight-character  alphanumeric  un '  t  identification 
beginning  with  B  or  R.  Example: 

GENERAL  SUPPORT-REINFORCING  UNIT  R1234TKB 

(r)  GO  TO  (label  of  procedure  statement).  GO  TO  is  a  pseudo 
order  used  to  direct  the  sequence  of  unit  procedure  statements  applicable  to 
a  unit.  The  data  element  is  an  alphanumeric  character  string  of  one  to  three 
characters.  In  the  following  example,  the  labeled  statement  is  also  shown. 

GO  TO  A12. 

A12:  STAY  FOR  3  HRS. 
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(s)  HEIGHT  OF  BURST  (height  Index).  The  data  element  la  an 
Integer  value  0,  1,  2,  3,  4.  Zero  is  used  for  a  nuclear  fire  event  in  which 
height  of  burst  of  the  munition  and  fuze  may  be  specified.  Where  munition 
and  fuze  permit  only  preset  heights  of  burst,  the  integer  1,  2,  3,  4  is  an 
index  to  the  preset  height  option  desired,  as  defined  through  Nuclear  Assess¬ 
ment  Model  constant  data.  Example: 

HEIGHT  OF  BURST  2 

(t)  IMPACT  RADIUS  (desired  height  of  nuclear  burst  in  meters) 

The  data  element  is  an  integer.  It  is  acted  upon  only  in  the  case  of  a 
nuclear  munition  and  fuze  which  allows  specification  of  height  of  burst, 
in  which  case  the  data  element  is  the  desired  height  of  burst  in  meters. 
Example: 


IMPACT  RADIUS  500M 

(u)  IN  BATTLE  (battle  identification).  The  data  element  is 
composed  of  no  more  than  eight  alphanumeric  characters.  Examples: 

IN  BATTLE  EIGHTCHR 
IN  BATTLE  X 
IN  BATTLE  1PLUS2 

(v)  MANDATORY.  No  data  required. 

(w)  MIX  (an  airmobile  aircraft  mix  index) .  The  data  element 
is  an  integer.  Example: 

MIX  3 

(x)  MUNITION  TYPE  (weapon/munition  code) .  The  data  element  Is 
a  four-character  code,  the  first  character  being  A  (conventional  round), 

N  (nuclear  round),  or  D  (atomic  demolition  munition).  Examples:  ^ 

■m 

A012 

NKX3 


(y)  NUMBER  OF  AIRCRAFT  (specified  number  of  aircraft).  The 
data  element  is  an  integer.  Example: 

NUMBER  OF  AIRCRAFT  4 

(z)  NUMBER  OF  ESCORTS  (specified  number  of  escort  aircraft). 
The  data  element  is  an  integer.  Example: 

NUMBER  OF  ESCORTS  6 
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(aa)  NUMBER  OF  ROUNDS  (specified  number).  The  data  element  is 
an  integer.  Example: 

NUMBER  OF  ROUNDS  187 

(bb)  NUMBER  OF  TRIPS  (specified  number  of  airmobile  lift  trips). 
The  data  element  is  an  integer.  Example: 

NUMBER  OF  TRIPS  2 

(cc)  NUMBER  OF  VOLLEYS  (specified  number).  The  data  element 
is  an  Integer.  Example: 

NUMBER  OF  VOLLEYS  1 

(dd)  ON  (location).  The  data  element  is  a  single  rectangular 
map  coordinate  entry  of  the  form  integer  -  integer.  Each  integer  can  be  one 
to  seven  digits  in  length.  If  fewer  than  seven  digits  are  used,  leading 
zeros  are  assumed  by  the  compiler.  Example: 

ON  1163590  -  1246780 

(ee)  OVER  (location  or  list  of  locations).  A  map  coordinate 
pair  or  list  of  as  many  as  eight  pairs  may  be  entered.  Each  pair  has  the 
form  integer  -  integer,  where  each  integer  can  be  one  to  seven  digits  in 
length;  leading  zeros  are  assumed  if  fewer  than  seven  digits  are  used.  Each 
location  is  to  the  nearest  meter.  Examples: 

OVER  163590  -  246780 

OVER  163590  -  246780,  163600  -  246800 

(ff )  PRIORITY  (movement  or  engineer  priority) .  The  data  element 
is  one  of  the  integer  values  1,  2,  3  or  4.  Example: 

PRIORITY  4 

(gg)  REINFORCING  UNIT  (UID  of  reinforced  unit).  The  data 
element  is  composed  of  eight  alphanumeric  characters,  the  first  of  which  must 
be  B  or  R.  Example: 

REINFORCING  UNIT  B1212123 

(hh)  STOP  TASK  (barrier  or  facility  identification).  The  data 
element  consists  of  three  alphabetic  and  three  numeric  characters.  Example: 

STOP  TASK  MNA017 
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(ii)  TARGET  NUMBER  (target  index  from  intelligence  report).  The 
data  element  is  an  integer.  Example: 

TARGET  NUMBER  480003 

(jj)  TO  (location  or  list  of  locations).  A  map  coordinate  pair 
or  list  of  pairs  may  be  entered.  Each  pair  has  the  form  integer  -  integer,  * 

where  each  integer  can  be  one  to  seven  digits  in  length;  leading  zeros  are 
assumed  if  fewer  than  seven  digits  are  used.  Each  location  is  to  the  nearest 
meter.  Examples: 

TO  163590  -  246780 

TO  163590  -  246780,  163600  -  246800 

(kk)  TYPE  (a  unit  type  designator).  The  data  element  is  composed 
of  four  alphabetic  characters.  Example: 

TYPE  BAMT 

J 

(11)  UNIT  (a  unit  identification).  The  data  element  consists  of 
eight  alphanumeric  characters,  the  first  of  which  is  B  or  R.  Example: 

UNIT  B1212123 

(mm)  UNTIL  (a  specified  time).  The  data  element  is  a  time  group 
as  described  above.  Examples: 

UNTIL  021215  ' 

UNTIL  02  DAYS  12  HOURS  15  MINUTES 

4.  DSL  CONDITIONAL  CLAUSES: 

a.  General.  Conditional  clauses  are  used  to  specify  the  user's  desired 
sequence  of  order  execution  when  that  sequence  depends  on  conditions  pre¬ 
vailing  prior  to  execution  of  an  order  or  during  or  upon  termination  of  an  » 
order  currently  being  executed.  Conditional  clauses  can  be  used  in  Unit 
Scenarios  and  in  Battle  Paragraphs.  As  with  order  clauses,  the  construction 

of  a  conditional  clause  is  governed  by  the  allowed  vocabulary  and  the  DSL 
syntax. 

b.  Conditional  Clause  Vocabulary.  A  limited  vocabulary  is  used  in  the  • 
construction  of  conditional  clauses.  This  vocabulary,  together  with  four 
possible  types  of  data  entries,  constitutes  the  totality  of  symbols  recognized 
by  the  DSL  Compiler  in  processing  conditional  clauses.  The  vocabulary  ele¬ 
ments  can  be  arranged  within  14  distinct  groups,  of  which  groups  1,  12,  13, 

and  14  are  data  entries:  * 


6 

Negator 

NOT 

7 

Unit's  activity 

ASSESSED,  FIRING,  MOVING, 
STOPPED 

* 

8 

Weather  condition 

CLOUD  COVER,  FOG  INDEX, 
RELATIVE  HUMIDITY, 
TEMPERATURE,  TEMPERATURE 
GRADIENT,  VISIBILITY  INDEX, 
WIND  DIRECTION,  WIND  SPEED, 
PRECIPITATION  INDEX 

9 

Location  of  weather 
condition 

AT  LOCATION 

l 

10 

Unit's  activity  with 
data 

HALTED  AT,  AT  LOCATION 

11 

Percent  indicator 

PERCENT 

t 

12 

Location  data 

A  pair  of  seven-digit  map 
coordinates;  e.g.,  0122000- 
0095750. 

§ 

13 

Quantity  data 

An  integer. 

14 

Time  data 

Formats  as  presented  in  subpar 
graph  3c(2). 

c.  Conditional  Clause  Syntax.  Syntax  established  for  the  DSL  Compile! 
allows  seven  conditional  clause  types,  where  a  clause  type  is  a  set  sequence 
of  elements  from  the  conditional  clause  vocabulary  groups.  The  types  are 
listed  below  with  one  example  of  each  type.  Parentheses  Indicate  a  group 
is  optional. 

Type  Pattern  Example 

A  1  2  (6)  5  13  (11)  B1234567  PRESENT  STRENGTH 

GREATER  THAN  150 

B  1  3  (6)  5  13  B1234567  EQUIPMENT  TYPE  172 

LESS  THAN  34 

C  18  (6)  5  13  (11)  B1234567  VISIBILITY  INDEX 

NOT  LESS  THAN  5 

D  8  9  12  (6)  5  13  (11)  CLOUD  COVER  AT  LOCATION 

0123500-0095000  NOT  GREATER  f 

THAN  70  PERCENT 

E  4  (6)  5  14  TIME  GREATER  THAN  011300 

F  1  (6)  7  B1234567  NOT  MOVING 

G  1  (6)  10  12  B1234567  AT  LOCATION 

0123000-0095800 

d.  Description  of  Conditions  being  Tested: 

(1)  Conditional  Type  A.  The  unit  for  which  the  test  Is  made  may  be 
any  resolution  unit  defined  within  the  system.  The  quantity  against  which  a 
check  is  made  is  the  quantity  present  in  the  specified  unit  of  personnel 
(PRESENT  STRENGTH);  Class  3,  or  equipment  item  2  (CLASS  3);  ammunition 
associated  with  individual  weapons,  or  equipment  item  6  (CLASS  5).  If  PERCENT"*, 
is  used,  the  quantity  against  which  a  check  is  made  is  the  ratio  of  the  amoun.. 
present  in  the  unit  to  amount  authorized.  Examples: 

B1234567  CLASS  3  NOT  LESS  THAN  2500 

B1234567  CLASS  5  GREATER  THAN  70  PERCENT 

B1234567  PRESENT  STRENGTH  LESS  THAN  150  , 

(2)  Conditional  Type  B.  The  unit  for  which  the  test  is  made  maybe 
any  resolution  unit  defined  within  the  system.  The  item  on  which  the  check 
is  to  be  made  is  specified  by  an  equipment  item  code  between  1  and  200.  The 
quantity  against  which  a  check  is  made  is  the  quantity  present  in  the  unit  or,  ' 
if  PERCENT  is  used,  the  ratio  of  quantity  present  to  authorized  quantity. 
Example: 
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B1234567  EQUIPMENT  TYPE  32  LESS  THAN  500 

B1234567  EQUIPMENT  TYPE  3  LESS  THAN  50  PERCENT 

(3)  Conditional  Type  C.  The  value  against  which  a  check  is  made  is 
the  current  weather  condition  at  the  location  of  the  specified  unit.  Legal 
values  of  the  data  entry  depend  on  the  weather  condition  being  checked.  The 
values  which  are  treated  as  percentages  are  so  indicated. 

(a)  Cloud  Cover.  The  data  value  can  be  an  integer  from  1  to  100. 
It  is  treated  as  a  percentage.  Example: 

B1234567  CLOUD  COVER  LESS  THAN  50  PERCENT 

(b)  Fog  Index.  The  data  value  can  be  0  (no  fog)  or  1  (fog). 
PERCENT  is  not  allowed.  Limitation  to  the  logical  operators  EQUAL  TO  and 
NOT  EQUAL  TO  is  suggested.  Example: 

B1234567  FOG  INDEX  EQUAL  TO  1 

(c)  Relative  Humidity.  The  data  value  must  be  between  1  and 
100.  It  is  treated  as  a  percentage.  Example: 

B1234567  RELATIVE  HUMIDITY  NOT  LESS  THAN  60  PERCENT 

(d)  Temperature.  The  data  entry  should  be  desired  temperature 
in  degrees  Fahrenheit.  Example: 

B1234567  TEMPERATURE  LESS  THAN  32 

(e)  Temperature  Gradient.  The  data  value  may  be  1  (inversion), 

2  (moderate  inversion),  3  (neutral),  or  4  (lapse).  Example: 


B1234567  TEMPERATURE  GRADIENT  LESS  THAN  3 

(f)  Visibility  Index.  The  data  entry  may  range  from  1  to  9 
where  9  denotes  best  and  1  denotes  poorest  visibility.  Example: 


B1234567  VISIBILITY  INDEX  NOT  LESS  THAN  6 

(g)  Wind  Direction.  The  data  value,  denoting  azimuth  in  degrees, 
may  range  from  0  to  360.  Example: 

B1234567  WIND  DIRECTION  NOT  LESS  THAN  45 


(h)  Wind  Speed.  The  data  entry  is  wind  speed  in  knots.  Example: 

B1234567  WIND  SPEED  NOT  LESS  THAN  12 

(i)  Precipitation  Index.  The  data  entry  may  have  a  value  of  0 
(no  precipitation),  1  (light  precipitation),  or  2  (heavy  precipitation). 
Example : 

B1234567  PRECIPITATION  INDEX  EQUAL  TO  0 

(4)  Conditional  Type  D.  The  value  against  which  a  check  is  made 

is  the  current  weather  condition  at  the  specified  location.  Rules  are  identi¬ 
cal  to  those  for  conditional  type  C. 

(5)  Conditional  Type  E.  The  value  within  the  clause  is  any  legal 
time  format  as  described  in  subparagraph  3c(2).  This  is  checked  against 
current  time.  Example: 

TIME  GREATER  THAN  011330 

(6)  Conditional  Type  F.  The  condition  checked  is  the  current  status 
of  the  specified  unit  as  follows: 

(a)  ASSESSED.  A  unit  is  sensed  as  ASSESSED  if  it  has  been 
attrited  by  the  Area  Fire  or  Air  Ground  Engagement  Models  within  the  past  15 
minutes.  Example: 

B1234567  NOT  ASSESSED 

(b)  FIRING.  A  unit  is  sensed  as  FIRING  If  It  has  received  a  DSL 
FIRE  order  or  a  TACFIRE  fire  mission  and  has  not  yet  completed  the  ordered 
fire  mission.  Example: 

B1234567  FIRING 

(c)  MOVING.  A  unit  is  sensed  as  MOVING  if  it  has  received  one 
of  the  following  orders  and  has  not  reached  the  final  movement  coordinates: 
MOVE,  FLY,  ADVANCE,  WITHDRAW,  If,  however,  the  order  is  ADVANCE  or  WITHDRAW 
and  the  unit  has  actually  engaged  in  ground  combat,  it  is  not  sensed  as 
moving.  Example: 

B1234567  MOVING 

(d)  STOPPED.  The  STOPPED  condition  is  exactly  equivalent  to 
NOT  MOVING,  and  MOVING  is  exactly  equivalent  to  NOT  STOPPED. 
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(7)  Conditional  Type  G.  The  condition  checked  is  whether  the 
specified  location  is  within  the  rectangular  area  defined  by  the  specified 
unit’s  current  location,  orientation,  width,  and  depth.  The  specified  unit 
must  be  a  resolution  unit.  Example: 

B1234567  NOT  AT  LOCATION  0123000-0095000. 

* 

5.  CONTROL  CARDS  AND  DECK  STRUCTURE.  This  paragraph  presents  control  cards 
required  by  the  DSL  Compiler,  structure  of  the  DSL  Compiler  data  deck,  and 
structure  of  decks  for  submittal  to  the  data  processing  facility. 

a.  Compiler  Control  Cards: 

(1)  The  DSL  Compiler  call  card  must  be  the  first  card  of  the  data 
deck.  This  card  has  one  of  the  following  forms: 

DSL. 

DSL,  DEBUG.  ) 

Position  on  the  punched  card  is  not  critical,  as  any  blanks  are  ignored; 
however,  the  first  entry  must  be  DSL,  and  the  designated  comma  and  period 
must  appear  as  indicated.  Use  of  the  DEBUG  option  causes  the  tables  generated 
by  the  DSL  compiler  to  be  listed. 

(2)  The  start  of  period  card  must  be  the  second  card  of  the  data 
deck.  This  card  has  the  form: 

START  OF  PERIOD:  XX  DAY  XX  HOUR  XX  MINUTE. 

where  XX  represents  an  appropriate  numeric  entry  such  as: 

START  OF  PERIOD:  01  DAY  18  HOUR  30  MINUTE. 

Presence  of  the  colon  and  period  as  illustrated  is  crucial.  To  indicate  ^ 

the  start  of  a  game,  the  card  must  appear  as  follows: 

START  OF  PERIOD:  01  DAY  00  HOUR  00  MINUTE. 

This  card  indicates  the  game  time  at  which  the  period  for  which  DSL  orders 
are  being  supplied  is  to  start.  , 

(3)  The  period  length  card  must  be  the  third  card  of  the  data  deck. 
This  card  must  be  of  the  form: 

PERIOD  LENGTH:  XXXX  MINUTES.  ' 


where  XXXX  represents  an  appropriate  numeric  entry  such  as: 


PERIOD  LENGTH:  480  MINUTES. 


The  colon  and  period  must  appear  as  indicated.  This  card  indicates  the 
length  of  the  period  of  combat  to  be  simulated  using  the  DSL  orders. 

(4)  The  final  card  of  the  DSL  data  deck  must  contain,  in  any  position 
on  the  card,  the  notation: 

FINIS. 

This  card  indicates  the  end  of  the  DSL  data  deck. 

(5)  Comments  may  be  inserted  at  any  position  in  the  data  deck 
following  the  third  card.  The  comment  is  used  to  provide  background  elabora¬ 
tion  of  the  operations  being  ordered  for  the  information  of  any  individual  who 
should  have  access  to  the  DSL  data  deck  or  a  listing  thereof.  Comments  have 
no  meaning  to  the  DSL  Compiler  or  to  any  other  processor  of  the  DSL  system 
and  exist  solely  for  user  convenience.  A  comment  must  be  introduced  by  one 

of  the  phrases  COMMENT:,  CONCEPT:,  or  CONCEPT  OF  OPERATION:,  where  the  colon 
is  an  integral  part  of  the  phrase.  A  comment  is  ended  with  a  period.  The 
body  of  a  comment,  between  the  introductory  phrase  and  closing  period,  may 
contain  any  symbol  except  a  period.  One  comment  may  be  of  any  length  up  to 
(and  including)  400  nonblank  characters.  A  DSL  data  deck  may  contain  as  many 
comments  as  desired.  Example: 

COMMENT:  SECOND  BRIGADE  SHOULD  NOW  BE  IN  ATTACK  POSITIONS; 

1ST  BN  ON  NORTH,  2ND  BN  ON  SOUTH  AND  3RD  BN  IN 
RESERVE  (EAST)  PD  SUPPORTING  ARTILLERY  (1ST  AND 
3RD  OF  307TH)  HAVE  FIRED  PREPARATORY  MISSIONS  AND 
GONE  TO  TACFIRE  MODE. 

b.  Data  Deck  Structure.  The  DSL  data  deck  contains  four  segments  as 
illustrated  in  Figure  B-2. 

(1)  The  first  segment  of  a  DSL  data  deck  must  comprise  the  compiler 
call  card,  start  of  period  card,  and  period  length  card,  in  that  sequence. 

(2)  Unit  Scenarios  comprise  the  second  segment  of  a  DSL  data  deck. 

The  order  in  which  individual  Unit  Scenarios  appear  is  not  critical,  although 
review  may  be  facilitated  by  keeping  scenarios  for  units  of  the  Red  force  and 
Blue  force  separate.  A  Unit  Scenario  is  acted  upon  only  if  the  specified  unit 
is  a  resolution  unit  or  has  a  personnel  strength  of  at  least  one.  Scenarios 
for  nonresolution  units  are  ignored,  unless  the  unit  should  attain  resolution 
status  as  the  result  of  an  appropriate  transfer  activity  order  (DETACH)  within 
the  scenario  of  another  unit.  In  this  case,  execution  of  the  scenario  com¬ 
mences  when  resolution  status  is  attained.  The  exception  is  a  scenario  with 
identification  ID:REDF0RCE.  or  ID:BLUEF0RC.  which  contains  all  engineer  activ¬ 
ity  orders  for  the  appropriate  force.  Comments  may  appear  within  any  Unit 
Scenario. 
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Figure  B-2.  DSL  Data  Deck  Structure 


(3)  Battle  Paragraphs  comprise  the  third  segment  of  a  DSL  data  deck. 
All  units  listed  in  battle  declaration  cards  of  Battle  Paragraphs  must  be  pro¬ 
vided  Unit  Scenarios  which  contain  appropriately  labeled  commands  keyed  to  the 
battle  conditionals  as 'discussed  in  subparagraph  2c.  Situations  may  arise 
where  a  DSL  data  deck  having  no  Battle  Paragraphs  is  appropriate,  which  is 
allowed  by  the  compiler. 

(4)  The  final  segment  of  a  DSL  data  deck  is  the  FINIS,  card. 

6.  DSL  RULES  AND  TECHNIQUES.  The  DIVWAG  Scenario  Language  provides  the 
gamer  with  a  wide  degree  of  latitude  in  controlling  simulated  units  within 
the  DIVWAG  system.  Proper  use  of  DSL  does,  however,  depend  upon  observation 
of  the  basic  vocabulary  and  syntax  rules  of  the  language.  Effective  use  also 
depends  upon  an  appreciation  of  the  model's  response  to  the  various  orders. 
This  paragraph  restates  some  of  the  more  critical  basic  DSL  rules  and  provides 
selected  guidelines  toward  effective  DSL  wijtiag  techniques.  As  with  any  lan¬ 
guage,  an  individual's  facility  with  DSL  strongly  depends  upon  the  extent  of 
his  exposure  to  and  experience  with  the  language.  Thus,  fluency  with  DSL  can¬ 
not  be  expected  simply  by  exposure  to  this  manual.  It  is  gained  through 
practice. 

a.  Elementary  Rules: 

(1)  Unit  Scenarios: 

,  (a)  A  Unit  Scenario  can  be  acted  upon  only  if  the  unit  is  a 

I  resolution  unit  and  has  personnel.  The  DSL  Compiler  will  accept  Unit  Scenar¬ 

ios  for  any  unit,  as  long  as  the  scenario  is  identified  with  a  legal  UID. 

The  DIVWAG  Period  Processor,  however,  will  ignore  orders  for  units  not  defined 
within  the  game,  for  nonresolution  units,  and  for  resolution  units  having  no 
personnel. 

(b)  A  Unit  Scenario  may  be  provided  for  a  nonresolution  unit  and 
that  unit  may  gain  a  resolution  status  through  appropriate  use  of  the  DETACH 

1  order  given  to  another  unit.  When  this  happens,  the  Unit  Scenario  Is  acted 

upon  at  the  time  resolution  status  is  gained. 

(c)  If  a  unit  loses  resolution  status,  through  the  JOIN  order 
in  its  own  Unit  Scenario  or  through  an  order  to  DETACH  its  last  subordinate; 
or  should  a  unit  lose  all  personnel;  it  will  not  execute  any  remaining  orders 
*  in  its  Unit  Scenario. 

(d)  A  unit  may  have  only  one  Unit  Scenario.  Presence  of  more 
than  one  Unit  Scenario  for  a  given  unit  causes  the  tables  generated  by  the 
,  DSL  Compiler  to  be  invalidated. 

(e).  A  Unit  Scenario  must  contain  at  least  one  command. 


€ 
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(f)  Liberal  use  of  labels  within  a  Unit  Scenario  is  a  key  to 
efficient  use  of  DSL.  Labels  must,  however,  be  unique  within  a  Unit  Scenario. 
The  sequence  of  orders  cannot  be  followed  as  the  user  intends  if  more  than 
one  command  has  the  same  label  in  one  Unit  Scenario. 

(2)  Battle  Paragraph/Unit  Scenario  Interface: 

(a)  Each  unit  listed  in  the  battle  declaration  card  must  be 
provided  a  Unit  Scenario. 

(b)  Within  the  Unit  Scenario  for  each  unit  listed  in  the  battle 
declaration  card,  properly  labeled  commands  must  appear. 

b.  Basic  DSL  Techniques: 

(1)  Timing.  It  is  generally  possible  to  control  the  time  at  which 
execution  of  an  order  begins  by  preceding  the  order  with  a  STAY  order  or  a 
PREPARE  order.  In  the  following  example,  the  STAY  order  is  used  to  time  a 
FIRE  order  and  a  MOVE  order. 


ID:B1111111. 

STAY  UNTIL  010530. 

FIRE  MUNITION  TYPE  A003  ON  0123000-0123000 
NUMBER  CF  VOLLEYS  4  IMPACT  RADIUS  100. 

STAY  UNTIL  010615. 

MOVE  TO  0118000-0127000.  J 

(2)  Repetitive  Orders.  It  is  generally  possible  to  repeat  a  sequence 
of  orders  using  the  GO  TO  order  with  appropriate  labels.  In  the  following 
example,  an  artillery  unit  is  ordered  to  fire  upon  a  series  of  three  targets 
repetitively.  A  time  conditional  is  used  to  exit  the  loop  when  time  exceeds 
021800. 

ID:B11111FA.  » 

STAY  UNTIL  021630.  + 

A1:FIRE  MUNITION  TYPE  A003  ON  0123000-0123000 
NUMBER  OF  VOLLEYS  3  IMPACT  RADIUS  100. 

FIRE  ON  0118000-0123000  MUNITION  TYPE  A003 
NUMBER  OF  VOLLEYS  3  IMPACT  RADIUS  100. 

FIRE  ON  0120000-0122525  NUMBER  OF  VOLLEYS  2  - 

MUNITION  TYPE  A003  IMPACT  RADIUS  100. 

IF  TIME  NOT  GREATER  THAN  021800,  THEN  GO  TO  Al. 

STAY  UNTIL  022000. 

(3)  Skipping  Commands.  Judicious  use  of  conditionals  with  the  GO  TO  ' 
order  permits  skipping  a  command  or  series  of  commands  as  the  situation  may 
dictate.  In  the  example  B123BN01  will  engage  in  one  of  two  battles  depending 
upon  the  strength  of  B123BN02.  The  command  with  label  ABC  will  be  executed 
upon  termination  of  either  battle  (Battle  Paragraphs  not  shown  here). 
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ID:B123BN01. 

PREPARE  UNTIL  020500. 

IF  B123BN02  PRESENT  STRENGTH  LESS  THAN  125,  THEN 

GO  TO  AAA. 

ADVANCE  TO  0125000-0113000. 

ENGAGE  IN  BATTLE  BIGHORN. 

AAA: ADVANCE  TO  0120000-0115500. 

ENGAGE  IN  BATTLE  FIREFITE. 

ABC : PREPARE  UNTIL  021200. 

c.  Techniques  Related  to  Models: 

(1)  Ground  Combat  Model.  Preparation  of  DSL  commands  for  the  Ground 
Combat  Model  Is  the  most  subtle  phase  of  DSL  preparation.  Functioning  of  the 
model  must  be  held  in  mind  as  orders  are  prepared. 

(a)  Battle  is  initiated  in  response  to  an  ADVANCE  order  followed 
by  an  ENGAGE  order.  Initiation  requires  scheduling  the  first  Ground  Combat 
Model  assessment  cycle  to  take  place  15  minutes  from  the  time  of  initiation. 
Initiation  takes  place  only  if  a  unit  on  the  other  force  is  currently  under 

a  PREPARE  or  a  WITHDRAW  order  and  is  within  3000  meters  (front  to  front)  of 
the  unit  receiving  the  ENGAGE  order. 

(b)  Assessment  of  battle  results  takes  place  at  the  scheduled 
time.  Assessment  will  cover  all  units  under  ADVANCE,  PREPARE,  or  WITHDRAW 
orders  at  the  time  of  assessment.  Only  units  under  an  appropriate  order  and 
within  3000  meters  of  an  opponent  who  is  also  under  an  appropriate  order 

are  treated.  Specification  of  attacker  and  defender  within  the  Ground  Combat 
Model  is  determined  by  the  one  unit  in  whose  scenario  the  ENGAGE  order  that 
caused  initiation  occurs.  All  units  on  the  initiator's  side  are  assessed  as 
attackers  and  all  units  on  the  opposing  side  are  assessed  as  defenders. 

(c)  Upon  completion  of  the  assessment  cycle,  all  conditionals  in 
the  Battle  Paragraph  are  checked  to  determine  if  the  battle  must  be  terminated. 
If  none  of  the  conditions  are  met,  another  assessment  cycle  is  scheduled  to 
take  place  in  15  minutes. 

(d)  A  battle  may  be  reinitiated  at  any  time  another  ENGAGE  order 
is  encountered.  Once  initiated  and  terminated,  a  battle  will  generally 
terminate  15  minutes  after  reinitiated.  .This  is  because  reinitiation  will 
schedule  a  15-minute  cycle,  and  the  conditional  that  terminated  the  battle 
the  first  time  will  generally  continue  to  be  true  and  will  generally  terminate 
the  battle  each  time  it  is  reinitiated. 

(e)  Upon  battle  termination,  all  units  listed  in  the  Battle 
Paragraph  will  progress  to  labeled  commands  as  indicated  by  the  battle  con¬ 
ditional  that  is  met.  This  occurs  regardless  of  whether  the  units  actually 
participated  in  the  battle.  The  command  under  execution  at  the  time  of  bat¬ 
tle  termination  is  not  generally  completed. 
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(f)  Battle  conditionals  are  checked  in  the  order  in  which  they 
appear  in  the  Battle  Paragraph.  Once  a  condition  is  met,  later  conditionals 
are  not  checked.  Thus,  if  several  conditions  are  included,  the  condition 
expected  to  occur  at  the  latest  time  should  generally  appear  first  in  the 
Battle  Paragraph. 

i 

(2)  Reconnaissance  Orders.  The  reconnaissance  control  code  is  of 
paramount  importance  in  a  RECONNOITER  order.  The  code  consists  of  four  char¬ 
acters,  C1C2C3C4,  where  the  first  character,  Cj_,  identifies  the  mission  type 
as  light  observation  helicopter  mission  (C^-H) ,  light  fixed  wing  aircraft 
mission  (Cj»F) ,  Mohawk  0V-1D  type  aircraft  mission  (Cj*M) ,  or  Air  Force 
reconnaissance  mission  (C^“A).  Meaning  of  successive  characters  of  the  code 
depends  upon  the  first  character. 

(a)  Control  Code  Determination: 

JL.  LOH/Fixed  Wing  Observation  Reconnaissance  Mission.  Code 
equals  H  or  F  C2C3C4*  J 

<1.  If  the  second  character,  C2,  is  R,  then  the  mission 
is  a  route  reconnaissance  mission;  otherwise,  it  is  an  area  reconnaissance 
mission.  If  it  is  an  area  reconnaissance  mission,  then  C2  has  values  1-9, 
where  the  integer  value  specifies  the  time  assigned  to  the  search  area  in 
units  of  15-minute  intervals.  For  example,  a  code  of  H326  specifies  an  area 
reconnaissance  mission  lasting  45  minutes  for  an  LOH. 

b^.  The  third  character,  C-j,  has  a  range  of  0-9  and 
specifies  the  route  deviation  limit  in  kilometers  (corridor  width)  which  the 
aircraft  will  not  exceed  during  the  flight.  In  the  example,  H326,  the  char¬ 
acter  2  in  the  third  position  specifies  that  the  LOH  will  reconnoiter  along 
routes  with  a  corrider  width  of  2  kilometers,  and  thus  will  never  exceed  the 
1-kilometer  deviation  limit  from  the  route  interval.  For  an  area  reconnaissance 
mission,  the  third  character  is  used  in  the  same  manner  and  effectively  creates 
a  density  of  reconnaissance  coverage;  i.e.,  successive  passes  over  the  assigned 
area  will  be  separated  by  the  corridor  width.  T 

_c.  The  fourth  character,  C^,  ranges  from  1-9  and  is  used 

for  two  purposes: 


.  is  the  sensor  load  combination  code  which 

identifies  the  list  of  sensor  types  carried  " 
on  board  the  aircraft 

•  is  also  the  combination  code  which  identifies 

the  correct  LOH  decision  control  matrix  to  * 
use  in  this  mission.  Note  that  the  same  sen¬ 
sor  load  is  required  to  use  the  same  decision 
matrix;  however,  with  up  to  10  combinations 


available,  it  is  possible  to  list  the  same 
sensor  load  with  different  decision  matrices. 

2_.  Mohawk  Type  Mission.  Code  equals  M  C2C3C4. 

This  type  reconnaissance  mission  is  currently  restricted 
to  represent  only  the  SLAR  MTI  with  GST  and  camera  sensor  types  on  board.  The 
fourth  character,  C4,  identifies  the  sensor  load  combination  carried  on  board 
in  the  same  manner  as  the  LOH.  The  first  sensor  type  in  the  combination  is 
currently  restricted  to  the  SLAR  MTI  with  GST. 

Is.  The  second  character,  C2,  is  used  to  set  the  range 
and  delay  of  the  SLAR  MTI  sensor  package  during  the  RECONNOITER  order  flight 
path.  The  allowed  values  of  C2  and  interpretations  are  shown  in  Figure  B-3 
where  the  values  of  DELAY,  RANGE  1,  RANGE  2,  and  RANGE  3  are  set  as  par"  of 
the  constant  data  base. 


Second  Character 
of  code 

SLAR  MTI  Settings 

Delay  Setting 

Range  Setting 

c2  -  0 

0  x  DELAY 

RANGE1 

c2  -  1 

lx  " 

II 

C2  -  2 

2  x  " 

II 

C2  -  3 

3  x  " 

II 

C2  -  4 

4  x  ” 

H 

C2  ■  5 

5  x  " 

II 

C2  •  6 

6  x  " 

II 

C2  -  A 

0  x  DELAY 

RANGE2 

C2  ■  B 

lx  " 

If 

C2  ■  C 

2  x  " 

II 

C2  -  D 

3  x  '' 

•1 

C2  -  E 

4  x  " 

•  1 

C2  -  F 

5  x  " 

•1 

c2  *  z 

0  x  DELAY 

RANGE3 

Figure  B-3.  Delay  and  Range  Settings  for  Mohawk  Type  Mission 


£,•  The  third  character, 
which  the  SLAR  i6  gated  as  being  to  the  right 
aircraft  flight  direction  as  follows: 


C3,  defines  the  direction(s)  for 
,  left,  or  to  both  sides  of  the 
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C3 

-  R, 

radar 

is 

gated 

on 

the 

right  side 

only 

c3 

■  L, 

radar 

is 

gated 

on 

the 

left  side 

only 

C3 

-  B, 

radar 

is 

gated 

on 

both 

sides 

_3.  Air  Force  Aircraft  Reconnaissance  Mission.  Code  equals 

A  X  X  C4. 


a.  The  second  and  third  characters  of  the  code  are  not 
currently  used  by  the  submodel  and  should  contain  X  X. 

b, .  The  fourth  character,  C4,  is  used  to  specify  the 
sensor  load  combination  on  board  as  in  previous  mission  types.  (Sensor  types 
are  currently  restricted  to  camera  systems.) 

(b)  DSL  Flight  Pattern  Data: 

1^.  The  DSL  order  also  specifies  the  flight  intervals  or  area 
over  which  the  reconnaissance  mission  is  to  be  flown.  The  coordinate  end¬ 
points  listed  on  the  DSL  order  form  the  actual  flight  path  taken  in  Mohawk 
OV-1D  and  Air  Force  reconnaissance  missions. 

2.  If  the  mission  is  an  area  reconnaissance  mission,  the 
coordinates  specify  the  four  corners  of  the  area  over  which  the  reconnaissance 
mission  is  to  be  flown.  The  order  of  the  points  appearing  in  the  DSL  order  is 
such  that  ?i?2^3^4  are  in  counterclockwise  order  around  the  enclosed  reconnais 
sance  area.  Also  PjP2  is  the  rear  boundary  from  which  the  reconnaissance  air¬ 
craft  will  start  the  coverage  of  the  area. 

3..  If  the  DSL  order  request  is  for  an  LOH  type  mission,  the 
actual  flight  path  does  not  follow  the  route  intervals  exactly  but  remains 
within  the  corridor  limits  defined  in  the  DSL  order  control  code. 

7.  DIVWAG  SCENARIO  LANGUAGE  VOCABULARY.  Figure  B-4  and  Figure  B-5  provide 
a  compendium  of  the  DSL  order  and  modifier  vocabulary  in  tabular  form. 

a.  DSL  Orders.  Figure  B-4  lists  the  DSL  order,  the  appropriate 
modifiers — required,  exclusive,  and  optional — for  that  order,  and  the  code 
number . 


b.  DSL  Order  Modifiers.  Figure  B-5  lists  the  modifiers  of  DSL  orders 
with  the  type  and  format  of  data.  Various  comments  are  included  regarding 
the  data  format. 
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Orders  Required  Modifiers  Exclusive  Modifiers*  Optional  Modifiers  Code  Number 
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Figure  B-4.  DSL  Orders  (continued) 
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Figure  B-5.  DSL  Order  Modifiers  (continued  on  next  page) 
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Figure  B-5.  DSL  Order  Modifiers  (continued) 
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Figure  B-5.  DSL  Order  Modifiers  (continued) 


Figure  B-5.  DSL  Order  Modifiers  (continued) 


Figure  B  5.  DSL  Order  Modifiers  (concluded) 


APPENDIX  C 


OPERATING  INSTRUCTIONS  REFERENCE  MANUAL 


1.  INTRODUCTION.  The  Operating  Instructions  program  of  the  Orders  Input 
Processor  provides  a  capability  to  add  or  update  specified  operational  param¬ 
eters  utilized  to  control  automatic  processor  occurring  within  the  model  prior 
to  each  game  period.  The  functions  performed  by  the  Operating  Instructions 
program  are  the  following: 

Placement  and  control  of  ground  based  sensors 
Introduction  of  intelligence 
Establishment  of  penetration  limits 
Allocation  of  close  air  support  sorties. 

This  appendix  provides  the  procedures  for  preparing  input  data  for  the  Operating 
Instructions  program.  The  four  following  paragraphs  describe  the  data  require¬ 
ments  for  each  function  listed  above.  The  final  paragraph  contains  the  procedure 
for  structuring  the  data  deck. 

2.  SENSOR  CONTROL.  The  DIVWAG  system  will  simulate  up  to  100  model  sensors 
for  each  opposing  force  where  a  model  sensor  is  an  individual  moving  target 
indicator  (MIT'*,  countermortar/counterbattery  (CM/CB) ,  or  air  defense  (AD) 
radar  or  an  unattended  ground  sensor  (UGS)  field.  Each  such  model  sensor  is 
defined  to  the  DIVWAG  system  through  the  use  of  the  OPERINS  loader.  A  dis¬ 
tinct  card  format  is  required  for  each  type  sensor  as  discussed  below.  Cer¬ 
tain  data  icems,  including  a  sensor  code,  unit  identification  (UID)  of  first 
node,  sensor  index,  sensor  reference  number,  and  sensor  status  code  are  com¬ 
mon  to  all  card  formats. 

a.  Data  Common  to  All  Sensors: 

(1)  Sensor  Code,  Each  generic  type  sensor  ie  identified  by  a  sensor 
code  which  appears  on  all  sensor  control  data  cards.  Permissible  values  of 
this  code  and  interpretations  are: 

02  »  short  range  MTI  radar 

03  »  medium  range  MTI  radar 

04  ■  long  range  MTI  radar 

05  *■  continuous  tracking  type  CM/CB  radar 

06  *  dual  beam  type  CM/CB  radar 

07  -  UGS  field 

08  ■  AD  radar. 

(b)  UID  of  First  Node.  Each  sensing  report  is  passed,  within  the 
Intelligence  and  Control  Model,  through  an  intelligence  communications  network 
for  decisions  and  processing.  (See  Volume  II,  Section  IV,  Chapter  6  for  a  de¬ 
tailed  discussion.)  Nodes  within  this  network  are  battalion,  brigade,  or 
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division  level  command  units.  This  entry  identifies  the  unit  that  is  nominally 
in  control  of  the  sensor  being  specified.  Each  sensor  will  use  the  unit  so 
identified  as  the  entry  point  into  the  network  for  all  sensing  reports  generated 
by  that  sensor.  The  UID  is  the  eight-character  alphanumeric  unit  identifier  of 
the  unit  to  be  specified.  This  unit  must  have  a  maneuver  type  unit  type  desig¬ 
nator  (UTD) ;  that  is,  the  third  character  of  this  unit's  UTD  must  be  M.  , 

(c)  Sensor  Index.  If  a  given  unit  (UID)  is  responsible  for  more 
than  one  MTI  radar,  more  than  one  CM/CB  radar,  more  than  one  AD  radar  or  more 
than  one  UGS  field,  the  sensor  index  is  used  to  determine  to  which  radar  or 
UGS  field  the  C 'ERINS  data  applies.  A  sequence  of  sensor  indexes,  starting 
with  1,  must  be  assigned  to  each  group  of  model  sensors  that  is  composed  of 
elements  from  one  of  the  above  categories  and  shares  the  same  first  node  UID. 

For  example,  if  a  given  unit  controlled  three  MTI  radars,  one  CM/CB  radar  an(j 
six  UGS  fields;  the  sensor  Indexes  applied  to  the  MTI  radar  would  be  1,  2* 

and  3;  to  the  CM/CB  radar  1;  and  to  the  UGS  fields  1,  2,  3,  A,  5,  and  6. 

(d)  Sensor  Reference  Number.  Hardware  characteristics  of  each 
type  sensor  are  defined  using  the  Intelligence  and  Control  Model  constant  data 
load  routines  (see  Volume  II,  Section  IV,  Chapter  6,  Appendix  A).  These  rou¬ 
tines  assign  a  reference  number  to  each  type  sensor.  This  reference  number  is 
used  to  specify  within  OPERINS  data  the  piece  of  hardware  desired.  The  refer¬ 
ence  number  is  obtained  from  the  printed  output  of  the  Intelligence  and  Control 
load  routines. 


code  are: 


Sensor  Status  Code.  Allowed  values  of  the  sensor  status 


1  -  available 

2  -  tracking 

3  ■  inoperative. 


The  status  code  is  set  dynamically  to  appropriate  values  by  the  Intelligence 
and  Control  Model.  An  entry  of  1  using  OPERINS  data  will  permit  full  play 
of  the  sensor  during  the  course  of  the  period.  An  entry  of  2  or  3  made  by 
OPERINS  is  not  reset  by  the  Intelligence  and  Control  Model  and  will  effec- 
tively  turn  off  the  sensor  through  the  course  of  the  period. 

b.  MTI  Radar.  The  essential  hardware  characteristics  of  this  type  radar 
are  entered  in  the  constant  data  input.  These  performance  characteristics 
are  not  changed  during  the  entire  game.  The  operating  instructions,  which  • 

the  gamer  is  expected  to  give,  are  those  that  deal  with  operating  constraints 
and  changes  in  the  situation  as  the  battle  progresses.  This  card  format  must 
be  prepared  for  each  sensor  played  either  to  define  the  sensor  initially  or  to 
change  a  previously  defined  sensor's  location,  status,  and  orientation.  There 
are  two  segments  in  the  input  card  format,  illustrated  in  Figure  C-l.  The  first' 
segment,  columns  1  through  18,  identifies  a  specific  radar  and  associates  its 
operating  unit  with  identification  details.  The  second  segment,  columns  20 
through  66,  specifies  the  location  and  other  operating  parameters. 
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(1)  Sensor  Code  (Columns  1-2) .  Each  generic  type  sensor  is  identif i 
by  a  sensor  code.  For  MTI  radar,  enter  the  value  02  (short  range),  03 
(medium  range) ,  or  04  (long  range) . 

(2)  UID  of  Controlling  Unit  (Columns  4-11).  Enter  the  eight-character 
UID  of  the  unit  that  is  to  receive  reports  from  this  sensor.  (This  must  be 

a  unit  having  an  M  as  the  third  character  of  its  UTD.)  ♦ 


(3)  Unique  Sensor  Index  (Columns  13-14).  When  the  controlling  unit 
is  responsible  for  more  than  one  MTI  radar,  this  index  is  used  to  discriminate 
among  the  radars.  The  index  must  be  assigned  serially,  starting  with  1  for 
the  first  MTI  radar  under  this  unit,  2  for  the  next  MTI  radar,  etc.  In 
relocating  or  reorienting  a  radar,  this  index  is  used  to  decide  which  radar 

to  move,  should  a  unit  be  responsible  for  more  than  one.  The  entry  is  right 
justified. 

(4)  Sensor  Reference  Number  (Columns  16-18).  Each  specific  type  of 
sensor  hardware  is  parametrically  defined  within  the  constant  data  input  on 
the  Intelligence  and  Control  Model  data  file.  In  the  process,  a  reference 
number  is  assigned  by  the  data  load  program.  Enter  this  number,  obtained 
from  the  load  program's  printed  output. 


(5)  Sensor  Status  Code  (Column  20).  The  status  of  the  radar  at  the 
beginning  of  the  game  or  period  is  to  be  entered  in  this  card  column. 

(6)  Sensor  Coordinates  (Columns  22-36) .  Enter  the  seven-digit 
X  and  Y  coordinates  of  the  sensor  right  adjusted  in  appropriate  columns. 

Leading  zeros  are  not  required. 

(7)  Assigned  Area  of  Search  (Columns  46-66).  The  area  of  search 

to  be  assigned  to  an  MTI  radar  is  specified  by  the  entries  on  columns  46-66. 
Columns  46-50  and  52-56  contain  the  minimum  and  maximum  ranges,  respectively, 
of  the  assigned  search  area,  in  meters.  Columns  58-61  contain  the  orientation, 
or  central  azimuth,  of  the  assigned  search  sector,  measured  clockwise  in  mils 
from  grid  north.  Columns  63-66  contain  the  width  of  the  assigned  search 
sector,  in  mils.  These  values  must  not  exceed  hardware  characteristics  as  I 
loaded  in  the  Intelligence  and  Control  Model  constant  data. 

c.  CM/CB  Radar.  The  hardware  characteristics  of  this  type  radar  were 
entered  in  the  constant  data  input.  These  characteristics  are  not  changed 
during  the  entire  game.  The  data  on  countermortar/counterbattery  radar 
loaded  as  Operating  Instruction  are  those  that  deal  with  operating  constraints' 
and  changes  in  the  situation  as  the  battle  progresses.  A  card  in  this  format 
(Figure  C-2)  must  be  prepared  for  each  sensor  played  either  to  define  the 
sensor  initially  or  to  change  a  previously  defined  sensor's  location  status 
or  orientation.  ^ 

(1)  Sensor  Code  (Columns  1-2).  Each  generic  type  sensor  is  identified 
by  a  sensor  code.  For  a  single  beam  continuous  tracking  CM/CB  radar,  set  the 
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Figure  C-2.  Countermortar/Counterbattery  Radar  Card  Format 


code  to  5.  For  a  dual  beam  CM/CB  radar,  set  the  code  to  6.  The  entry  must 
be  right  justified. 

(2)  UID  of  First  Node  in  Communication  Net  (Columns  4-11),  Enter 
the  eight-character  UID  of  the  unit  that  will  be  the  first  node  in  a  communica 
tion  network  from  this  specific  radar  site.  This  unit  must  be  a  maneuver 
unit  (i.e.,  have  the  character  M  in  the  third  character  of  the  UTD) . 

(3)  Unique  Sensor  Index  (Columns  13-14),  When  this  receiving  node 
has  more  than  one  CM/CB  radar  reporting  to  it,  this  index  is  used  to  dis¬ 
criminate  among  the  radars.  The  index  must  be  assigned  serially,  starting 
with  1  for  the  first  CM/CB  radar  reporting  to  this  unit,  2  for  the  second, 
etc.  In  relocating  or  reorienting  a  radar,  this  index  is  used  to  decide 
which  radar  to  move  or  reorient,  should  the  unit  have  more  than  one  reporting 
to  it.  The  entry  must  be  right  justified. 

(4)  Sensor  Reference  Number  (Columns  16-18).  Each  specific  type  of 
sensor  hardware  is  parametrically  defined  within  the  constant  data  input  on 
the  Intelligence  and  Control  Model  data  file.  In  the  process,  a  reference 
number  is  assigned  by  Che  data  load  program,  and  it  is  this  number  that  is 
required  here  to  tie  this  particular  radar  to  a  set  of  hardware  data. 

(5)  Sensor  Status  Code  (Column  20).  The  status  of  the  radar  at  the 
beginning  of  the  game  or  period  is  to  be  entered  in  this  card  column.  Enter¬ 
ing  a  2  or  3  will  preclude  the  radar  from  detecting  and  recognizing  targets 
during  the  course  of  the  period.  Entering  a  1  will  permit  full  play  of  the 
radar  during  the  course  of  the  period. 

(6)  Sensor  Coordinates  (Columns  22-36).  Enter  the  seven-digit  X 
and  Y  coordinates  of  the  sensor.  The  entry  must  be  right  justified,  and 
leading  zeros  are  not  required. 

(7)  Dual  Beam  Status  (Column  44),  This  is  a  status  code  for 
dual  beam  CM/CB  radars  only  (i.e,,  sensor  code  6).  This  flag  is  used  to 
indicate  the  desired  operational  status  of  the  radar.  Possible  entries  are; 

0  *  monitor  low  angle  fire  only 

1  *  monitor  high  angle  fire  only 

2  *  switch  back  and  forth  to  monitoring 

low  and  high  angle  fire. 

The  radar  must  have  this  capability. 

(8)  Center  Azimuth,  a  (Columns  58-61).  This  Che  orientation  or 
center  azimuth  of  Che  search  sector,  measured  in  mils  from  grid  north. 

Entry  must  be  right  justified. 

(9)  Search  Sector,  l  (Columns  63-66).  This  is  the  assigned  search 
sector  width,  in  mils.  If  this  search  sector  is  more  than  two  times  the 


sector  coverage  capability  of  the  hardware  (see  beam  description  variables  in 
Volume  II,  Appendix  A  to  Chapter  6  of  the  Period  Processor,  Section  IV  for 
Countermortar/Counterbattery  Radars),  there  will  be  a  coverage  gap  in  the 
center  of  the  assigned  search  sector.  Entry  must  be  right  justified. 

(10)  Site  Mask  Angle,  ^(Columns  68-71).  This  is  the  site  mask  angle 
measured  in  mils,  and  it  must  be  right  justified  in  the  field. 

d.  AD  Radar.  Hardware  characteristics  of  the  radars  are  entered  in  the 
Intelligence  and  Control  Model  constant  data  files  (see  Volume  II,  Section  IV, 
Chapter  6,  Appendix  A).  These  hardware  characteristics  are  not  to  be  exceeded 
by  those  in  the  Operating  Instructions  input.  The  operating  instructions  that 
the  gamer  is  expected  to  provide  on  AD  sensors  are  those  that  deal  with  oper¬ 
ating  constraints  and  changes  in  the  situation  as  the  battle  progresses.  This 
card  format  must  be  prepared  for  each  AD  radar  to  be  played.  Format  of  the 
input  card  is  shown  on  Figure  C-3. 

(1)  Sensor  Code  (Columns  1-2).  Each  generic  type  of  sensor  is 
identified  by  a  sensor  code.  For  AD  radar,  enter  the  value  08. 

(2)  UID  of  First  Node  in  Communication  Net  (Columns  4-11).  Enter 
the  eight-character  UID  of  the  unit  that  will  be  the  first  node  In  a 
communication  network  from  this  specific  radar  site.  This  unit  must  be  a 
maneuver  unit  (i.e.,  have  the  character  M  in  the  third  character  of  the  UTD) . 

(3)  Unique  Sensor  Index  (Columns  13-14).  When  this  receiving  node 
has  more  than  one  AD  radar  reporting  to  it,  this  index  is  used  to  discriminate 
among  the  radars.  The  index  must  be  assigned  serially,  starting  with  1  for 
the  first  AD  radar  reporting  to  this  unit,  2  for  the  second,  etc.  In  relocat¬ 
ing  or  reorienting  a  radar,  this  index  is  used  to  decide  which  radar  to 

move  or  reorient,  should  the  unit  have  more  than  one  reporting  to  it.  The 
entry  must  be  right  justified. 

(4)  Sensor  Reference  Number  (Columns  16-18).  Each  specific  type  of 
sensor  hardware  is  parametrically  defined  within  the  constant  data  input  on 
the  Intelligence  and  Control  Model  data  file.  In  the  process,  a  reference 
number  is  assigned  by  the  data  load  program,  and  it  is  this  number  that  is 
required  here  to  tie  this  particular  radar  to  a  set  of  hardware  data. 

(5)  Sensor  Status  Code  (Column  20).  The  status  of  the  radar  at  the 
beginning  of  the  game  or  period  is  to  be  entered  in  this  card  column.  Enter¬ 
ing  a  2  or  3  will  preclude  the  radar  from  detecting  and  recognizing  targets 
during  the  course  of  the  period.  Entering  a  1  will  permit  full  play  of  the 
radar  during  the  course  of  the  period. 

(6)  Sensor  Coordinates  and  Height  (Columns  22-44).  Enter  the  seven¬ 
digit  X,  Y  coordinates  and  height  in  meters  of  the  sensor  right  adjusted  in 
the  appropriate  columns.  Leading  zeros  are  not  required. 
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Figure  C-3.  Air  Defense  Radar  Card  Format 


(7)  Assigned  Area  of  Search  (Columns  46-76).  The  area  of  search 
to  be  assigned  to  an  AD  radar  is  specified  by  the  entries  in  columns  46-76. 
Columns  46-50  and  52-56  contain  the  minimum  and  maximum  ranges,  respectively, 
of  the  assigned  search  area,  in  meters.  Columns  58-61  contain  the  orientation, 
or  central  azimuth,  of  the  assigned  search  sector,  measured  in  mils  clockwise 
from  grid  north.  Columns  63-66  contain  the  width  of  the  assigned  search 
sector,  in  mils.  Columns  68-71  contain  the  vertical  central  azimuth  of  the 
search  area,  in  mils.  Columns  73-76  contain  the  width  of  the  vertical  search 
sector,  in  mils. 

e.  Unattended  Ground  Sensors.  This  section  describes  the  card  formats 
required  to  represent  unattended  ground  sensor  fields.  Each  UGS  field  re¬ 
quires  three  data  cards.  The  first  card  contains  data  necessary  to  identify 
the  UGS  field,  the  second  card  specifies  the  composition  of  the  UGS  field, 
and  the  third  card  specifies  the  location  of  the  field.  The  format  of  each 
of  these  cards  is  discussed  below. 

(1)  UGS  Identification  (Figure  C-4).  This  card  specifies  the  sensor 
code,  UID  of  the  controlling  unit,  unique  sensor  index,  sensor  status,  and  the 
median  time  to  track  and  report  enemy  units. 

(a)  Sensor  Code  (Columns  1-2) .  Each  generic  type  of  sensor  is 
identified  by  a  sensor  code.  For  UGS  fields,  enter  the  value  07. 

(b)  UID  of  First  Node  in  Communication  Net  (Columns  4-11).  Enter 
the  eight-character  UID  of  the  unit  that  will  be  the  first  node  in  a  communica¬ 
tion  network  from  this  specific  UGS  field.  This  unit  must  be  a  maneuver  unit 
(i.e.,  have  the  character  M  in  the  third  character  of  the  UTD) . 

(c)  Unique  Sensor  Index  (Columns  13-14).  When  this  receiving 
node  has  more  than  one  UGS  field  reporting  to  it,  this  index  Is  used  to 
discriminate  among  the  fields.  The  index  must  be  assigned  serially,  starting 
with  1  for  the  first  UGS  field  reporting  to  this  unit,  2  for  the  second,  etc. 

(d)  Sensor  Status  Code  (Column  20).  The  status  of  the  UGS 
field  at  the  beginning  of  the  game  or  period  Is  to  be  entered  in  this  card 
column.  Entering  a  2  or  3  will  preclude  the  field  from  detecting  and  recogniz¬ 
ing  targets  during  the  course  of  the  period.  Entering  a  1  will  permit  full 
play  of  the  field  during  the  course  of  the  period. 

(e)  Median  Time  to  Track  and  Detect  (Columns  39-44).  Enter  the 
median  time  in  seconds,  from  activation  of  this  UGS  field  to  receipt  of  a 
sensing  report  at  the  first  communication  node. 

(2)  UGS  Field  Composition  (Figure  C-5).  This  card  specifies  the 
composition  of  the  UGS  field.  Field  composition  is  defined  in  terms  of  the 
number  of  each  distinct  type  of  UGS  that  is  located  within  the  field.  Up  to 
10  different  types  of  UGSs  may  be  present  in  a  given  field.  See  Volume  II, 
Section  IV,  Appendix  A  to  Chapter  6,  for  a  discussion  of  UGS  types. 
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Figure  C-5.  Unattended  Ground  Sensor  Field  Composition  Card  Format 


(a)  Sensor  Type  (Columns  2-3).  The  sensor  type  identifies  the 
specific  kind  of  UGS.  This  sensor  type  must  agree  with  the  definition  given 
in  the  UGS  constant  data  (Volume  II,  Section  IV,  Chapter  6). 

(b)  Number  (Columns  5-7).  Enter  the  number  of  sensors,  of  the 
type  specified  above,  to  be  placed  in  the  UGS  field. 

(c)  The  remainder  of  the  card  has  space  for  defining  nine 
additional  sensor  types  and  their  numbers. 

(3)  UGS  Field  Location  (Figure  C-6).  This  card  specifies  the 
battlefield  locations  of  the  UGS  field  by  listing  the  four  corner  coordinates 
of  the  field.  The  shape  of  an  UGS  field  is  restricted  to  a  convex  quadri¬ 
lateral.  A  geometric  figure  is  said  to  be  convex  if  it  is  possible  to  connect 
any  two  points  in  the  figure  by  a  straight  line  that  lies  entirely  within  the 
figure.  The  geometric  figure  shown  as  (a)  below  (Figure  C-7)  is  convex;  the 
figure  shown  as  (b)  is  not.  The  order  in  which  the  corners  are  input  is 
arbitrary. 


Figure  C-7.  Geometric  Figures 


(a)  X  coordinate  (Columns  2-8).  Enter  the  seven-digit 
X  coordinate  of  the  first  corner  of  the  field.  Leading  zeros  are  not  required 

(b;  Y  coordinate  (Columns  10-16).  Enter  the  seven-digit 
Y  coordinate  of  the  first  corner  of  the  field. 

(c)  The  remainder  of  the  card  contains  the  coordinates  of  the 
remaining  three  corners. 

3.  INTRODUCTION  OF  INTELLIGENCE.  While  the  DIVWAG  Period  Processor  simulates 
a  range  of  ground-based  and  aerial  sensors  generally  available  to  a  division 
in  the  field,  explicit  simulation  of  all  potential  sources  of  battlefield 
intelligence  is  not  attempted.  The  ability  is  available  through  the  OPERINS 
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Figure  C-6.  Unattended  Ground  Sensor  Location  Card  Format 


loader  to  introduce  additional  intelligence  to  the  model.  This  capability 
is  intended  to  permit  the  control  team  to  enrich  the  intelligence  picture 
available  to  the  opposing  player  teams  in  a  closed  or  semi-closed  game  while 
maintaining  the  information  within  the  format  that  is  generally  used  for 
intelligence  in  the  DIVWAG  system.  It  also  permits  specification  of  targets 
for  attack  within  the  Air  Ground  Engagement  Model  or  for  automatic  allocation 
of  fire  support,  should  this  prove  necessary.  In  all  cases,  use  of  this 
feature  should  be  stringently  controlled  by  the  game's  control  team. 

a.  Approach.  Intelligence  introduced  to  the  DIVWAG  Period  Processor 

through  the  OPERINS  loader  enters  and  is  processed  by  the  Intelligence  and  * 
Control  Model  similarly  to  intelligence  gathered  by  sources  explicitly  mod¬ 
eled.  The  data  input  by  the  OPERINS  loader  is  formatted  to  produce  a  sensing 
report  similar  to  those  generated  within  the  model.  The  input  data  format 
permits  the  user  to  control  the  time  at  which  this  sensing  report  enters  the 
Intelligence  and  Control  Model,  the  node  in  the  intelligence  communication 
network  at  which  the  sensing  report  enters  the  system,  and  whether  the  report 
passes  through  the  intelligence  processing  portions  of  the  model,  the  fire  \ 

support  allocation  portions  of  the  model,  or  both.  Details  of  the  Intelli-  ’ 

gence  and  Control  Model  communications  network,  processing,  and  fire  support 
allocation  logic  are  found  in  Volume  II,  Section  IV,  Chapter  6. 

b.  Card  Formats.  Three  card  formats  are  prescribed  for  the  introduction 
of  intelligence  with  the  OPERINS  loader.  The  period  card  is  prepared  only 
once  for  each  game  period  in  which  intelligence  is  introduced.  For  each 
sensing  report  to  be  introduced,  one  intelligence  information  card  and  one 
estimated  equipment  card  are  produced. 

(1)  Period  Card.  The  period  card,  illustrated  in  Figure  C-8,  is  the 
first  data  card  of  an  intelligence  data  deck  processed  by  the  OPERINS  loader. 

The  information  provided  on  this  card  is  needed  to  correctly  schedule  time  of 
entry  of  sensing  reports  into  the  Intelligence  and  Control  Model.  The  symbols 
PERIOD,  DAY,  HOUR,  MINUTE  and  a  period  are  preprinted  on  the  coding  form  at 
columns  1-6,  12-14,  19-22,  27-32,  and  33  respectively  and  must  be  punched  on 

the  data  card.  Data  to  be  provided  are  the  starting  time  of  the  game  period  ^ 
for  which  intelligence  is  to  be  introduced.  Start  of  period  in  terms  of  day, 
hour,  and  minute  are  placed  in  columns  9-10,  16-17,  and  24-25,  respectively. 

Each  entry  is  right  justified. 

(2)  Intelligence  Information.  This  card  format,  shown  in  Figure  C-9, 

is  the  first  of  two  cards  requred  for  each  item  of  intelligence  to  be  introduced, 
into  the  system. 

(a)  Source  Type  Code  (Columns  1-2).  The  source  type  code  is  a 
gamer  or  control  group  classification  of  the  information  source.  Within  the 
model,  its  function  is  simply  one  of  mechanical  bookkeeping;  and  processing  ^ 

of  each  sensing  report  is  identical,  regardless  of  the  nature  of  the  infor¬ 
mation  source  specified.  Legal  codes  and  their  nominal  source  interpretation 
are: 
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Figure  C-8,  Period  Card  Format 
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ormation  Card  Format 


31 

x 

Prisoners  of  war 

32 

X 

Civilians 

33 

m 

Recovered  military  personnel 

34 

X 

Captured  enemy  documents 

35 

x 

Enemy  materiel 

36 

m 

Stay-behind  units 

37 

s 

Agencies  for  operation  behind  enemy  lines 

38 

X 

Other  sources. 

(b)  Where  to  Code  (Columns  4-7).  This  code  establishes  the  type 
of  action  to  be  taken  upon  the  sensing  report  within  the  Intelligence  and  Con¬ 
trol  Model.  Legal  codes  and  indicated  actions  are: 

.  INTL  -  Enter  report  only  in  intelligence  processing  and 
communication  net 

.  FSCC  -  Enter  report  only  in  the  fire  support  allocation 
logic  of  the  model 

.  BOTH  -  Enter  report  both  in  intelligence  processing  and 
communication  net  and  in  fire  support  allocation  logic. 

(c)  Source  UID  (Columns  9-16) .  Enter  the  eight-character 
alphanumeric  UID  of  a  unit  to  whom  the  information  is  first  available.  This 
unit  will  function  as  the  first  node  in  the  communication  network  for  the 
sensing  report  and  must  be  a  battalion,  brigade,  or  division-level  maneuver 
unit . 


(d)  Target  UID  (Columns  18-25).  Enter  the  eight-character 
alphanumeric  UID  of  the  target  unit;  i.e.,  the  unit  described  by  this 
report. 


(e)  Time  (Columns  27-33).  Enter  the  time  at  which  the  information 
is  to  enter  the  Intelligence  and  Control  Model.  Upon  entry  the  report  is  proc¬ 
essed  as  any  sensing  report  in  the  model,  and  the  user  must  be  aware  of  deci¬ 
sion  and  processing  delay  times  that  will.be  applied.  Enter  the  day  in  columns 
27-28,  the  slash  (/)  in  column  29,  and  the  time  (24-hour  clock)  in  columns  30- 
33.  For  example,  02/0830  represents  0830  hours  on  the  second  day  of  simulated 
combat . 


(f)  Estimated  Location  (Columns  35-49).  Enter  the  seven-digit 
X  and  Y  coordinates  of  the  estimated  location  of  the  target  unit.  Entries 
are  right  justified  in  columns  35-41  (X  coordinate)  and  43-49  (Y  coordinate) 
and  leading  zeroes  may  be  omitted. 

(g)  Estimated  Activity  (Columns  51-54).  The  estimated  activity 
of  the  target  unit  at  time  of  entry  of  the  report  into  the  system  is  required. 
Legal  activity  codes  for  the  unit  are: 
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MOVE  *•  Unit  moving 

FIRX  -  Unit  firing  tube  artillery 

FIRM  ■  Unit  firing  missile  artillery 
FIRA  =  Unit  firing  air  defense  weapons 
ATCK  *  Unit  in  an  attack  posture 
DEFN  =  Unit  in  a  defensive  posture 
WTHD  -  Unit  withdrawing 

ENGR  «  Unit  involved  in  engineering  activity 

STAY  ■  Unit  stationary  and  not  otherwise  active. 


(h)  Estimated  Move  Rate  (Columns  56-57).  If  the  estimated 
activity  is  MOVE,  ATCK,  or  WTHD,  enter  the  estimated  rate  of  unit  movement 
in  meters  per  minute;  otherwise,  leave  the  field  blank. 


t 


(i)  Estimated  Direction  (Columns  61-63).  If  the  estimated 
activity  is  MOVE,'  ATCK,  or  WTHD,  enter  the  estimated  direction  of  movement; 
otherwise,  leave  the  field  blank.  Directions  are  expressed  as  points  of  the 
sixteen-point  compass,  and  entries  are  right  justified  within  the  field. 
Legal  entries  are: 
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NNE 

ESE 

ssw 

WNW 

NE 

SE 

sw 

NW 

ENE 

SSE 

wsw 

NNW 

(3)  Estimated  Equipment.  This  card  format,  shown  in  Figure  C-10,  is 
the  second  of  two  cards  required  for  each  item  of  intelligence  to  be  introduce, 
into  the  system.  This  information  is  used  within  the  model  to  develop  estimated* 
type  and  size  of  the  target  unit. 

(a)  Personnel  (Columns  1-4).  Estimated  number  of  personnel 
obtained  from  source. 

(b)  Vehicles  (Columns  6-8).  Estimated  number  of  vehicles,  other 
than  those  in  categories  described  below,  obtained  from  source. 

i> 

(c)  Tanks  (Columns  10-12).  Number  of  tanks  estimated  by  source 
about  the  target. 

(d)  APCs  (Columns  14-16).  Estimated  number  of  APCs  in  target 
obtained  from  source. 

(e)  Artillery  Tubes  (Columns  18-20).  Number  of  artillery  tubes 
estimated  by  information  source. 

(f)  Artillery  Missiles  (Columns  22-24).  Estimated  number  of  * 

artillery  missiles  in  target. 

(g)  Air  Defense  Guns  (Columns  26-28).  Number  of  AD  guns  estimated 
by  source  to  be  in  target  unit. 
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ESTIMATED  EQUIPMENT 


(h)  Air  Defense  Missiles  (Columns  30-32).  Estimated  number  of  AD 
missiles  in  target  unit. 

(i)  Aircraft  (Columns  34-36).  Estimated  number  of  aircraft 
obtained  from  information  source. 

4.  HELICOPTER  AND  ARTILLERY  PENETRATION  LIMITS.  This  card  format,  shown  at  S 

Figure  C-ll,  sets  limiting  ranges  beyond  which  helicopter  and  artillery  fire 
support  missions  will  not  be  requested  by  the  fire  support  allocation  logic  of 
the  Intelligence  and  Control  Model.  Ranges  are  stated  in  terms  of  distance 
beyond  the  FEBA.  The  Period  Processor  actually  calculates  a  rectilinear  f 

approximation  of  the  trace  of  the  FEBA  to  be  used  in  reaching  fire  support 
allocation  decisions.  Since  the  model's  approximation  of  the  FEBA  may  not 
coincide  with  the  FEBA  on  game  maps  plotted  by  the  user,  the  calculation  of 

the  model  FEBA,  as  described  in  Volume  II,  Section  IV,  Chapter  5,  should  be 
understood  prior  to  assignment  of  these  ranges.  The  user  should  be  aware  that 
ranges  are  initially  set  to  zero  within  the  model  and  should  be  set  to  desired 
values  at  the  first  game  period. 

J 

a.  Blue  Helicopters  (Columns  2-7).  Enter  in  meters  the  maximum  range 
beyond  the  FEBA  to  which  Blue  attack  helicopter  missions  may  be  automatically 
requested  within  the  model. 

b.  Blue  Artillery  (Columns  9-14).  Enter  in  meters  the  maximum  range 
beyond  the  FEBA  to  which  Blue  artillery  fire  missions  may  be  automatically 
reqeusted  within  the  model. 

c.  Red  Artillery  (Columns  16-21).  Same  definition  as  columns  9-14. 

5.  CLOSE  AIR  SUPPORT  SORTIES.  These  Cfrd  formats  are  used  to  set  the  number 
of  TACAIR  sorties  available  to  the  Blue  and  Red  forces.  They  are  initialized 
at  zero  and  must  be  set  by  OPERINS  data  to  obtain  TACAIR  simulation. 

a.  Blue  Sortie  Constraints  (Figure  B-12) .  It  is  assumed  that  all  Blue 
sorties  will  be  conducted  by  all-weather-capable  aircraft.  Sorties  are  allo¬ 
cated  in  6-one  hour  blocks,  starting  at  midnight;  and  unused  sorties  in  one  ^ 
block  are  not  carried  over  to  later  blocks.  Entries  are  the  maximum  number  of  " 
sorties  available  from  0001  to  0600  (columns  1-5) ;  from  0601  to  1200  (columns 
6-10);  from  1201  to  1800  (columns  11-15);  and  from  1801  to  2400  (columns  16-20). 

b.  Red  Sortie  Constraints  (Figure  B-13).  Both  all-weather-ca  able  aircraft 
and  aircraft  limited  to  good  visibility  conditions  are  played  for  Red.  The  good  « 
visibility  aircraft  are  flown  first,  conditons  and  sortie  limits  permitting; 
otherwise,  allocation  of  sorties  is  as  for  Blue  TACAIR.  Enter  maximum  Red  all¬ 
weather-capable  sorties  for  the  time  blocks  0001  to  0600;  0601  to  1200;  1201  to 
1800;  and  1801  to  2400  in  columns  21-25;  26-30;  31-35  and  36-40  respectively.  « 


6.  OPERINS  DATA  DECK  STRUCTURE, 
composed  of  up  to  four  subdecks. 


The  data  deck  for  the  OPERINS  loader  is 
Any  or  all  of  these  decks  may  be  provided 
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Figure  C-ll.  Helicopter  and  Artillery  Penetration  Limits  Card  Format 


Figure  C-13.  Card  Format  for  Red  Sorties 


for  one  operation  of  the  loader.  Each  subdeck  is  introduced  by  a  header  card 
with  the  proper  code  punched  in  the  first  two  columns.  Legal  header  card 
codes  and  associated  subdecks  are: 

01  Sensor  control  subdeck 
02  Introduction  of  intelligence  subdeck 
03  Helicopter  and  artillery  penetration  subdeck 
04  Close  air  support  sorties  subdeck. 

a.  Subdeck  Structure: 

(1)  Sensor  Control  Subdeck.  The  first  card  of  the  sensor  control 
subdeck  is  a  header  card  with  the  symbols  01  punched  in  the  first  two  card 
columns.  Following  the  header  card,  sensor  control  data  cards  may  be  provided 
in  any  sequence  with  the  requirement  that  the  three  cards  required  to  establish 
an  UGS  field  must  be  contiguous  and  in  the  order  presented  in  Paragraph  lie 
(UGS  Identification,  UGS  Field  Composition,  UGS  Field  Location)  for  each  UGS 
field.  The  user  should  bear  in  mind  the  limit  of  100  model  sensors  (radars 

or  UGS  fields)  per  force.  The  size  of  this  subdeck  is  not  fixed;  and  the  last 
card  of  the  subdeck  must  be  a  blank  card,  used  to  signal  the  end  of  the  subdeck 
to  the  loader. 

(2)  Introduction  of  Intelligence  Subdeck.  The  first  card  of  this 
subdeck  must  be  the  header  card  with  the  symbols  02  punched  in  the  first  two 
card  columns.  The  second  card  of  this  subdeck  must  be  the  Period  Card, 
described  in  Paragraph  3b (1).  For  each  sensing  report  to  be  introduced  into 
the  system,  the  Intelligence  Information  Card  must  be  followed  immediately  by 
the  Estimated  Equipment  Card.  There  is  no  practical  limit  on  the  number  of 
such  card  pairs  to  be  processed.  The  size  of  this  subdeck  is  not  fixed;  and 
the  last  card  of  the  subdeck  must  be  a  blank  card,  used  to  signal  the  end  of 
the  subdeck  to  the  loader. 

(3)  Helicopter  and  Artillery  Penetration  Subdeck.  This  subdeck 
consists  of  the  header  card,  with  03  punched  in  the  first  two  card  columns, 
followed  by  one  data  card  as  discussed  in  Paragraph  4. 

(4)  Close  Air  Support  Sorties  Subdeck.  This  subdeck  is  composed  of 
a  header  card,  with  04  punched  in  the  first  two  card  columns,  followed  by  a 
Blue  Sortie  Card,  followed  by  a  Red  Sortie  Card.  All  three  cards  must  be 
present  in  the  proper  order. 

b.  Deck  Structure.  Only  those  subdecks  required  for  the  game  period  need 
be  included  in  the  data  deck.  The  order  of  subdecks  within  the  data  deck  is 
of  no  significance  as  long  as  each  subdeck  starts  with  the  proper  header  card. 
An  end  of  data  deck  card,  with  99  punched  in  columns  1-2  of  the  card,  must  fol¬ 
low  the  last  subdeck.  A  typical  data  deck  is  shown  in  Figure  C-14. 

c.  Control  Cards.  The  instructions  for  preparing  the  control  cards  and 
work  request  form  are  contained  in  Appendix  A  of  this  volume. 
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Figure  C-14.  Typical  Data  Deck  Arrangement  for  Operating  Instructions 


APPENDIX  D 


ANALYSIS  OUTPUT  PROCESSOR  USERS  GUIDE 


1.  PURPOSE.  The  purpose  of  chls  appendix  is  to  provide  prospective  users 
with  the  procedures  and  techniques  necessary  to  operate  the  Analysis  Output 
Processor. 

2.  BACKGROUND.  The  Analysis  Output  Processor  is  designed  to  reduce  the 
volume  of  data  produced  by  the  Period  Processor  of  the  DIVWAG  system  into 
manageable  sets  of  data  for  analysis  and  perform  the  numerical  operations  of 
the  statistical  process  described  in  Analytical  Methodologies,  which  is  Vol¬ 
ume  II  of  the  DIVWAG  documentation  set  published  in  December  1971.1  The 
Analysis  Output  Processor  performs  three  functions: 

.  data  extraction 

.  data  display 

.  statistical  calculations. 

a.  The  data  extraction  and  display  routines  of  the  Analysis  Output 
Processor  extract  game  output  data  from  the  period  history  tapes  produced  by 
the  Period  Processor  and  array  the  data.  This  process  is  accomplished  utiliz¬ 
ing  computer  programs  that  scan  the  complete  set  of  game  history  data,  extract 
data  by  type  of  information  desired,  merge  the  data,  and  array  the  data  into 
the  proper  subsets  as  input  for  the  statistical  computations. 

b.  The  statistical  calculations  function  of  the  Analysis  Output  Processor 
performs  the  numerical  operations  of  both  the  parametric  and  nonparametric 
statistical  analyses  of  the  game  output.  The  details  of  the  statistical  anal¬ 
ysis  techniques  appear  in  Analytical  Methodologies.  The  statistical  calcula¬ 
tion  results  in  a  final  rank  ordering  of  units  and  systems  for  each  functional 
area  of  combat.  A  detailed  description  of  the  Analysis  Output  Processor  is 
contained  in  Section  VI  of  Volume  III  of  this  documentation.  The  procedures 
for  using  the  processor  are  described  in  the  following  paragraphs. 

3.  COMPUTER  INTERFACE  PROCEDURES: 

a.  Steps  in  Processing.  There  are  four  major  steps  in  us.  g  the  Analysis 
Output  Processor,  excluding  the  step  of  listing  some  or  all  of  the  records  on 
the  period  history  tapes.  The  steps  are  as  follows. 

.  History  tape  preparation  and  data  extraction 


1.  Development  of  a  Division  War  Game  Model  (DIVWAG) ,  Analytical 
Methodologies  (Volume  II),  USACDC  Combat  Systems  Group  study,  December  1971. 


.  Data  display 

.  Subjective  evaluation  of  data 

.  Data  correction  and  statistical  analysis. 

The  first  and  second  steps  may  be  performed  as  one  computer  job.  With  the 
output  of  this  job,  the  analyst  may  perform  the  third  step  and  structure  the 
input  for  the  fourth  step,  which  also  may  be  run  as  one  job.  These  two  jobs 
and  a  third  tape  listing  job  are  described  in  the  following  subparagraphs. 

b.  Preparation,  Extraction,  and  Display  Job.  This  job  executes  the 
routine  PREP  to  preprocess  the  period  history  tapes.  Routine  ANCARD  and  one, 
two,  or  all  extractor  routines — AFM,  AGM,  and  GCMOD— -are  used  to  extract  data 
from  the  abbreviated  preprocessed  period  history  tape.  Data  are  arrayed  by 
these  routines  in  the  form  required  by  the  analysis  routines,  routine  MTXMRG 
is  used  to  display  the  arrays  and  to  write  the  output  of  the  extraction  rou¬ 
tines  onto  magnetic  tape.  Since  the  DIVWAG  data  file  is  a  required  input  for 
routine  ANCARD,  the  utility  routine,  UTILLD,  must  also  be  executed  to  load 
the  data  file  onto  disk. 

(1)  Data  Card  Preparation: 

(a)  Data  Cards  for  Routine  PREP.  A  single  card  is  input  to 
routine  PREP.  An  example  of  the  card  format  is  illustrated  in  Figure  D-l  and 
contains  4  to  18  input  values. 

_1.  Columns  1-2.  The  number  of  period  history  tapes  from 
which  records  are  to  be  selected  is  entered,  right-justif led  in  columns  1  and 
2.  In  the  figure,  record  types  111,  112,  241,  242,  311,  312,  and  313  are 
selected  from  two  tapes. 

2.  Columns  3-16.  The  minimum  and  maximum  times  for  records 
to  be  selected  are  entered,  right-justif led,  in  columns  4-9  and  11-16  respec¬ 
tively.  Columns  3  and  10  are  separator  columns.  The  minimum  and  maximum 
times  are  packed  in  the  form  ddhhmm,  where  dd  is  day,  hh  is  hour,  and  mm  is 
minute.  See  Figure  D-l. 

J3.  Columns  18-80.  The  1  to  16  record  types  to  be  selected 
are  entered  in  columns  18-20,  22-24,  26-28,  and  so  forth  through  78-80.  Col¬ 
umns  17,  21,  25,  29,  and  so  forth  to  77  are  ignored.  Blanks,  commas,  dashes, 
or  any  other  characters  may  be  used  as  separators  in  these  columns. 

(b)  Data  Cards  for  Routine  ANCARD.  Eight  types  of  input  cards 
are  recognized  by  routine  ANCARD.  They  are  unit  identification  (UID)  cards, 
unit  type  designator  (UTD)  cards,  time  cards,  equipment  cards,  quantity-rate 
(Q-R)  cards,  killer  selection  cards,  combination  cards,  and  the  END  (of  in¬ 
put)  card.  For  ^ach  extractor  routine  to  be  used:  (1)  one  to  ten  classes 
(matrix  rows)  must  be  defined  using  UID  and/or  UTD  cards;  (2)  the  time  inter¬ 
vals  (matrix  columns)  must  be  defined  using  time  cards;  (3)  the  matrices  to 
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Figure  D-l.  Input  Card  Format  for  Routine  PREP 


be  constructed  must  be  defined  using  equipment  cards  for  AFM/AGM  and/or 
killer  selection  cards  (and  optionally  combination  cards)  for  GCMOD;  and  (4) 
the  kinds  of  matrices  must  be  defined  using  Q-R  cards.  The  last  card  in  the 
input  deck  must  be  an  end  card.  Diagnostics  are  not  issued  if  input  for  one 
or  more  extractor  routines  is  incomplete,  and  this  condition  is  not  fatal  to 
execution  of  routine  ANCARD  (and  may  not  be  fatal  to  execution  of  the  extrac¬ 
tor  routine).  It  is  the  responsibility  of  the  user  to  insure  that  the  input 
is  complete.  The  formats  and  data  for  each  of  the  eight  card  types  are  dis¬ 
cussed  in  the  follow'ng  subparagraphs.  A  combined  example  of  the  input  cards 
for  routine  ANCARD  is  shown  in  Figure  D-2. 

1.  UID  Card.  This  card  defines  a  row  (class)  by  UID  of  the 
units  to  be  included. 


a.  Model  to  be  Selected  (Columns  1-2) .  This  entry  may  be 
01,  02,  or  03,  where  01  is  the  Area  Fire  Model,  02  is  the  Air  Ground  Engage¬ 
ment  Model,  and  03  is  the  Ground  Combat  Model. 


column  3. 


_b.  Card  Type  (Column  3) .  The  number  1  must  be  entered  in 


£.  Class  (or  Row)  to  Which  DID  Card  Applies  (Columns  4-5). 
The  class  (1-10)  is  entered,  right- justified,  in  these  columns. 


d.  UID  to  be  Selected  (Columns  11-18,  20-27,  29-36,  38-45, 
47-54,  56-63,  and  65-72).  A  UID  must  contain  eight  alphanumeric  characters 
and  begin  with  B  or  R.  An  exception  is  if  the  class  is  to  contain  all  Blue 
or  all  Red  units,  wherein  the  mnemonic  ALLB  or  ALLR  respectively  is  entered 
in  columns  11-14. 


e.  Additional  Cards.  Additional  cards,  prepared  as 
above,  are  required  when  more  than  seven  UIDs  are  to  be  defined  in  one  class. 

J2.  UTD  Card.  This  card  defines  a  row  (class)  by  UTD  of  the 
units  to  be  included. 

a.  Model  Code  Number  (Columns  1-2).  The  entry  is  01, 

02,  or  03. 

b.  Card  Type  (Column  3).  The  number  2  is  entered. 

jc.  Class  (or  Row)  of  Matrix  to  Which  UTD  Card  Applies 
(Columns  4-5).  The  class  (1-10),  right- justified,  is  entered. 

<1.  UTD  to  be  Selected  (Columns  11-14,  16-19,  21-24,  and 
so  Forth  to  71-74).  A  UTD  must  be  four  alphameric  characters,  and  is  entered 
in  these  columns. 


e.  Additional  Cards.  Additional  cards,  prepared  as  above, 
are  required  when  more  than  13  UTDs  are  specified. 
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_3 .  Time  Card.  The  time  card  defines  the  matrix  columns, 
(i.e.,  the  length  of  the  time  Interval  for  the  Area  Fire  and  Air  Ground 
Engagement  Model  matrices,  and  the  Individual  interval  end  points  for  each 
column  of  the  Ground  Combat  Model  matrices) .  The  Area  Fire  and  Air  Ground 
Engagement  Models  require  only  one  time  card  each  specifying  the  length  of 
the  interval;  however,  the  Ground  Combat  Model  requires  at  least  one  time 
card  for  each  row  (class). 

a.  Model  Code  Number  (Columns  1-2) .  The  entry  can  be 

01,  02,  or  03. 

b.  Card  Type  (Column  3) .  The  number  4  is  entered  for 
the  Area  Fire  Model  time  card.  The  number  5  is  entered  for  the  Air  Ground 
Engagement  Model.  The  number  3  is  entered  when  the  time  card  applies  to  the 
Ground  Combat  Model. 


Class  (or  Row),  to  Which  the  Times  Apply  (Columns 
4-5).  This  field  is  applicable  only  to  Ground  Combat  time  cards.  For  other 
models,  all  classes  have  the  same  time  intervals. 

<1.  Time  Interval  in  Minutes  (Columns  11-16) .  This  field 
applies  only  to  the  Area  Fire  and  Air  Ground  Engagement  Models.  Enter  the 
length  of  the  time  interval  (right  justified)  in  mlnue6  to  be  used. 

e.  Ground  Combat  Model  Time  Interval  Boundary 
Specifications  (Columns  11-16  and  18-23,  25-30  and  32-37,  39-44  and  46-51, 
and  53-58  and  60-65).  Two  entries  are  required  to  define  a  time  interval, 
and  each  card  allows  the  specification  of  four  time  intervals  for  a  Ground 
Combat  Model  class.  The  first  entry  of  each  pair  of  columns  on  the  card  is 
the  interval  starting  time,  and  the  second  is  the  interval  ending  time.  The 
times  must  all  be  in  ascending  order  on  each  Ground  Combat  Model  time  card. 
The  first  Ground  Combat  Model  time  card  encountered  will  specify  time  inter¬ 
vals  for  the  first  four  entries  in  a  row;  the  second  card  encountered  for 
that  row  (class)  specifies  the  time  intervals  for  the  next  four  entries,  etc. 
A  dash  or  hyphen  may  be  used  between  the  times  defining  a  time  interval,  and 
a  comma  may  be  used  to  separate  interval  pairs;  however,  both  hyphens  and 
commas  are  optional. 

4,.  Equipment  Card.  This  card  is  used  to  specify  equipment 
types  for  which  each  analysis  matrix  is  to  be  build. 

a.  Model  Code  Number  (Columns  1-2).  The  entry  can  be  01 
(Area  Fire)  or  02  (Air  Ground  Engagement)  only. 

b.  Card  Type  (Column  3).  The  entry  must  be  3. 

c_.  Equipment  Number  for  Which  a  Matrix  Should  Be  Built 
(Columns  11-13,  14-16,  ...,  74-76,  and  77-79).  Equipment  numbers  must  be 
right  justified. 


d_.  Additional  Cards.  Additional  cards,  prepared  as 
above,  are  required  when  the  equipment  types  for  which  matrices  are  being 
build  exceed  23  items  (maximum  is  25). 

_5.  Quantity-Rate  (Q-R)  Cards.  The  Q-R  card  is  used  to 
select  matrices  containing  data  in  quantity  or  rate  form  for  either  losses 
or  effects. 

a.  Model  Number  (Columns  1-2).  Entry  can  be  01,  02,  or 
03. 

b.  Card  Type  (Column  3).  Enter  5  for  Area  Fire,  7  for 
Air  Ground  Engagement,  or  4  for  Ground  Combat. 

c^.  Quantity  of  Losses  (Column  11) .  Enter  1  if  quantity 
of  losses  matrices  are  desired.  Leave  blank  if  matrix  is  not  desired. 

<1.  Rate  of  Losses  (Column  12) .  Enter  1  if  rate  of  losses 
matrices  are  desired.  Leave  blink  if  matrix  is  not  desired. 

€i.  Quantity  of  Effects  (Column  13).  Enter  1  if  quantity 
of  effects  matrices  are  desired.  Leave  blank  if  matrix  is  not  desired. 

Rates  of  Effects  (Column  14) .  Enter  1  if  the  rates 

of  effects  matrices  are  desired.  Leave  blank  if  matrix  is  not  desired. 

6^.  Killer  Selection  Card.  This  card  is  used  to  select  the 

killers  whose  victims  are  to  be  used  in  building  Ground  Combat  analysis 
matrices. 

a. .  Model  Number  (Columns  1-2).  These  columns  must  have 
03  entered  since  thi6  card  is  applicable  only  to  the  Ground  Combat  Model. 

b.  Card  Type  (Column  3).  The  column  must  have  5  entered. 

c.  Mnemonic  or  Comment  (Columns  4-10).  Optional  entry. 

d_.  Killer  Ordinal  (Columns  11-12,  ...,  41-42).  The 
killer  ordinal  refers  to  the  row  number  of  the  killer  in  the  killer-victim 
matrix  output  by  the  Ground  Combat  Model  in  the  Period  Processor  technical 
output.  The  ordinal  may  have  a  value  from  1  to  16  and  is  right  justified. 

7_.  Combination  Card.  The  combination  card  is  used  to  inform 
the  Ground  Combat  Model  data  extractor  how  to  combine  (matrix  addition) 

Ground  Combat  Model  victim  matrices. 

a.  Model  Number  (Columns  1-2).  The  entry  must  be  03. 

b.  Card  Type  (Column  3).  The  entry  must  be  6. 


_c.  Combined  Matrix  Definition  (Columns  11-20,  21-30, 

31-40 . and  61-70).  Each  10-column  group  may  contain  any  combination 

of  numbers  from  1  to  9.  The  matrix  for  each  of  the  victims  specified  in  a 
group  are  added  together  and  the  sum  matrix  will  be  subjected  to  analysis  as 
well  as  each  of  the  nine  victim  matrices. 

8^.  End  Card.  A  card  with  END  in  columns  1-3  is  required  to 
signify  the  end  of  the  data  deck. 

(c)  Data  Card  for  Routine  AFM.  No  card  input  is  required  if 
only  one  abbreviated  period  history  tape  created  by  one  of  the  tape  prepro¬ 
cessors  is  to  be  input.  If  more  than  one  history  tape  is  to  be  input,  a 
single  card  with  the  number  of  history  tapes  to  be  input  right  justified  in 
columns  9  and  10  is  required. 

(d)  Data  Card  for  Routine  AGM.  No  card  input  is  required  if 
only  one  abbreviated  period  history  tape  created  by  one  of  the  tape  prepro¬ 
cessors  is  to  be  input.  If  more  than  one  history  tape  is  to  be  input,  a 
single  card  with  the  number  of  history  tapes  to  be  input  right  justified  in 
columns  9  and  10  is  required. 

(e)  Data  Card  for  Routine  GCMOD.  No  card  input  is  required  if 
only  one  abbreviated  period  history  tape  created  by  one  of  the  tape  prepro¬ 
cessors  is  to  be  input.  If  more  than  one  history  tape  is  to  be  input,  a 
single  card  with  the  number  of  history  tapes  to  be  input  right  justified  in 
columns  9  and  10  is  required. 

(2)  Deck  Structure.  Figure  D-3  illustrates  the  control  cards  and 
input  decks  required  to  execute  the  first  two  steps  of  the  Analysis  Output 
Processor.  In  this  example,  all  three  extractor  routines  are  executed. 

(3)  Job  Request  Form.  Figure  D-4  shows  the  job  request  form  to 
accompany  the  job  of  the  previous  example. 

(4)  Discussion: 

(a)  Control  Cards.  The  job  of  this  example,  XTRCT,  requires 
120,000  (octal)  words  of  central  memory,  the  central  processing  unit  (CPU) 
time  limit  is  set  to  777  (octal)  seconds.  One  nine-track  tape  drive  and  one 
seven-track  drive  are  used.  The  first  task  the  job  performs  is  to  retrieve, 
from  the  disk  library,  the  executable  binary  routines,  copy  six  complete  rou¬ 
tines,  and  return  the  library  to  the  system.  The  Period  Processor  dump  tape 
is  mounted  on  a  nine-track  tape  drive  and  the  utility  routine,  UTILLD,  is 
attached  and  executed  to  load  the  DIVWAG  data  file  onto  disk.  The  dump  tape 
is  unloaded  and  the  file,  UTILLD,  is  returned  to  the  system.  The  third  task 
is  execution  of  routine  ANCARD.  This  task  is  performed  before  the  preproces¬ 
sing  step  to  minimize  the  amount  of  disk  storage  the  job  controls  at  any  one 
time.  Following  execution  of  ANCARD,  the  disk  area  into  which  the  DIVWAG 
data  file  was  loaded  and  the  routine  are  returned  to  the  system.  The  fourth 
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task  is  preprocessing.  The  first  period  history  tape  is  mounted  on  a  nine- 
track  tape  drive.  The  routine  PREP  is  executed.  The  remaining  period  history 
tapes  are  mounted,  in  turn,  on  the  same  tape  drive  under  program  control  dur¬ 
ing  this  execution.  Following  execution  of  PREP  the  last  history  tape  is 
unloaded,  and  the  routine  and  tape  drive  are  returned  to  the  system.  The 
fifth  task,  data  extraction,  is  performed  by  routines  AFM,  AGM,  and  GCMOD. 
These  routines  operate  on  input  disk  files  TAPE2  and  TAPE3  created  by  routines 
ANCARD  and  PREP  respectively,  and  utilize  large  disk  scratch  files  (TAPE1) 
during  execution.  After  each  execution  in  this  task,  the  routine  executed 
and  the  scratch  file  are  returned  to  the  system  and  the  output  file,  TAPE4, 
is  copied  to  another  disk  file,  TAPE27,  to  be  used  as  input  for  the  next  task. 
The  final  task,  data  display,  is  performed  by  routine  MTXMRG.  An  output  tape, 
TAPE28,  is  mounted  on  a  seven-track  drive  and  the  program  is  executed. 

(b)  Input.  The  data  deck  illustrated  in  Figure  D-3  corresponds 
to  a  file  contining  nine  records.  The  first  record  is  the  deck  of  control 
cards  discussed  above.  The  second  through  seventh  records  are  COPYN  instruc¬ 
tion  cards;  i.e.,  input  for  the  routine  COPYN  which  is  executed  six  times  dur¬ 
ing  the  first  task.  The  routine  UTILLD,  executed  during  the  second  task, 
requires  no  input;  the  eighth  record  is  the  input  deck  for  routine  ANCARD. 

The  final  record  is  the  input  card  for  PREP.  The  extractor  routines  and  rou¬ 
tine  MTXMRG  default  to  the  correct  input  for  execution  if  there  are  no  input 
cards;  i.e.,  the  extractors  expect  the  single  abbreviated  period  history  file 
created  by  routine  PREP,  and  routine  MTXMRG  expects  one  input  file  containing 
the  combined  output  of  the  extractor  programs. 

c.  Data  Correction  and  Statistical  Analysis.  This  job  executes  routine 
MTXUP  to  replace  nonsignificant  entries  in  the  matrices  with  null  numbers  and 
routine  ANALYS  to  perform  the  statistical  calculations. 

(1)  Data  Card  Preparation: 

(a)  Data  Cards  for  Routine  MTXUP.  A  number-of-tapes  card  and 
any  number  of  update  data  cards  are  input  for  routine  MTXUP.  These  card  types 
are  described  in  the  following  subparagraphB. 

_1.  Number-of-Tapes  Card.  The  number  of  tapes  to  be  input  is 
entered  in  columns  4  and  5. 

_2.  Update  Data  Card.  Five  values  are  entered  on  each  update 
data  card.  They  are  the  output  record  number  (El  number)  of  the  matrix  to  be 
updated  (columns  1-5).  The  model  code — 01,  02,  or  03 — of  the  extractor  rou¬ 
tine  which  created  the  record  (columns  6-10) ,  the  column  (columns  11-15)  and 
row  (columns  16-20)  of  the  zero  entry  in  the  matrix  to  be  updated,  and  the 
new  value  of  the  entry  (columns  23-27).  All  values  must  be  right  justified 
in  the  Indicated  columns.  The  update  cards  must  be  sequenced  in  ascending 
order  by  output  record  number.  Figure  D-5  shows  an  example  of  an  update  card. 
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(b)  Data  Cards  for  Routine  ANALYS.  Routine  ANALYS  requires  a 
number-of- tapes  card  and  two  data  cards  per  effectiveness  measure  partition 
for  each  partition  to  be  calculated.  These  input  cards  are  described  in  the 
f  ollowing  subparagraphs . 

1.  Number -of -Tapes  Card.  This  card  indicates  the  number  of 
tapes  to  be  input  in  columns  4  and  5. 

2.  Data  Cards.  For  each  effectiveness  measure  partition,  a 
card  indicating  the  effectiveness  measure  number  (columns  3-4)  and  the  output 
record  numbers  of  the  matrices  (effectiveness  indicator  number)  which  make  up 
the  partition  (columns  11-13,  14-16,  ....  68-70),  and  a  card  indicating  the 
desired  level  of  confidence  (alpha  level)  must  be  input.  The  level  is  indi¬ 
cated  by  the  following  code  numbers  in  column  5  of  the  card. 

Code  Alpha  Level 

1  0.10 

2  0.20 

3  0.30 

4  0.40 

5  0.50 

All  input  values  are  right  justified  in  the  Indicated  columns  of  the  cards. 

See  Figure  D-6  for  an  example  of  the  first  card  type  described  above. 

(2)  Deck  Structure.  Figure  D-7  shows  the  control  cards  and  input 
decks  to  execute  this  Job. 

(3)  Job  Request  Form.  Figure  D-8  shows  the  Job  request  form  to 
accompany  the  above  example. 

(4)  Discussion: 

(a)  Control  Cards.  The  job  of  this  example,  ANALYS,  requires 
120,000  (octal)  words  of  central  memory.  The  central  processing  unit  (CPU) 
time  limit  is  set  to  177  (octal)  seconds.  One  seven-track  tape  drive  is  used. 
The  first  task  the  job  performs  is  to  retrieve,  from  the  disk  library,  the 
executable  routines,  copy  the  two  complete  routines — MTXUP  and  ANALYS — and 
return  the  library  to  the  system.  The  output  tape  from  the  previous  job  is 
mounted  on  a  seven-track  drive,  routine  MTXUP  is  executed,  and  the  tape,  tape 
drive,  and  routine  are  returned  to  the  system  in  the  second  task.  The  final 
task  is  execution  of  routine  ANALYS. 

(b)  Input.  The  deck  in  Figure  D-7  corresponds  to  a  file 
containing  five  records.  The  first  record  is  the  deck  of  control  cards.  The 
second  and  third  records  contain  the  COPYN  instruction  cards;  i.e.,  input  for 
the  two  executions  of  the  routine  COPYN.  The  fourth  record  is  the  input  deck 
for  routine  MTXUP,  and  the  final  record  is  the  input  deck  for  routine  ANALYS. 
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Figure  D-7.  Data  Correction  and  Statistical  Analysis 
Deck  Structure 


d.  Tape  Listing  Job.  Any  number  of  period  history  tapes  created  by  the 
Period  Processor  or  abbreviated  period  history  tapes  created  by  either  of  the 
preprocessor  routines,  PREP  or  PTAPE,  may  be  listed  by  the  tape  listing  rou¬ 
tine,  PH1ST.  The  following  example  shows  the  technique  used  to  generate  an 
abbreviated  period  history  tape  using  routine  PTAPE  and  list  it.  Since  rou¬ 
tine  PTAPE  uses  the  output  of  routine  UXR,  and  routine  UXR  requires  the  DIVWAG 
data  file,  which  must  be  loaded  to  disk  using  routine  UTILLD,  these  two  rou¬ 
tines  are  also  executed. 

(1)  Data  Card  Preparation: 

(a)  Data  Cards  for  Routine  UXR.  No  card  input  is  required. 

(b)  Data  Cards  for  Routine  PTAPE.  An  input  tapes  data  card,  1  to 
50  sets  of  selection  criteria  cards,  and  an  end  selection  criteria  card  are 
required. 


.1.  Input  Tapes  Data  Card.  The  first  input  card  contains  two 
integer  values.  The  first  value,  right-justif led  in  column  10,  is  the  number 
of  period  history  tapes  from  which  records  are  to  be  selected.  The  second 
value,  right-justified  in  column  20,  is  1  for  normal  executions  or  2  if  dup¬ 
licate  sets  of  period  history  tapes  are  to  be  input. 

_2.  Selection  Criteria  Sets.  Each  set  contains  at  least  two 
cards;  any  number  (including  zero)  of  selection  criteria  cards,  a  device  card, 
and  an  end  card.  All  cards  are  free  form;  blanks  are  Ignored.  Four  types  of 
selection  criteria  cards  are  allowed,  and  are  described  in  the  following 
subparagraphs . 


a.  Unit  Identification  (UID)  Criteria  Card.  The  UID 
criteria  card  allows  the  user  to  select  event  records  of  a  single  unit  or  a 
set  of  units  by  specifying  the  appropriate  UIDs.  The  format  of  the  card  re¬ 
quires  the  key  characters  "UID  »"  followed  by  the  unit  identifications  which 
must  be  separated  by  commas.  The  card  size  limits  the  number  of  eight- 
character  UIDs  on  one  card  to  seven;  however,  any  number  of  UID  cards  may  be 
Included  in  a  set,  and  one  to  seven  UIDs  may  be  on  any  card.  The  maximum 
number  of  units  is  100.  If  it  is  desired  to  select  all  of  the  units  in  either 
the  Blue  force  or  Red  force,  the  form  of  the  card  is  UID  ■  ALLB  for  Blue  or 
UID  <■  ALLR  for  Red.  If  no  UID  card  is  included  in  a  criteria  set,  all  units 
are  acceptable  dependent  on  the  other  criteria. 

t>.  Unit  Type  Designator  (UTD)  Criteria  Card.  The  UTD 
criteria  card  allows  the  selection  of  a  single  unit  type  or  a  set  of  unit 
types  by  listing  appropriate  UTDs.  The  format  of  the  UTD  card  requires  the 
key  characters  "UTD*"  followed  by  the  UTDs  which  must  be  separated  by  commas. 
UTDs  may  be  either  actual  four-character  UTDs  or  partial  UTDs,  in  which  one 
to  three  of  the  UTD  characters  are  masked  with  asterisks  (*)  to  indicate  that 
only  the  unmasked  characters  are  significant.  The  card  size  limits  the  number 
of  UTDs  on  one  card  to  15;  however,  any  number  of  UTD  cards  may  be  included 


D-17 


in  a  set,  and  any  number  of  UTDs  may  be  on  any  one  card.  The  limiting 
constraint  is  that  the  number  of  units  should  not  exceed  100.  If  no  UTD  card 
is  included  in  a  criteria  set,  all  unit  types  are  acceptable  dependent  on  the 
other  criteria. 


c.  Time  (TIM)  Criteria  Card.  Game  time  may  be  applied 
as  a  criterion  for  the  selection  of  event  records  by  use  of  the  TIM  criteria 
card.  The  format  of  the  TIM  criteria  card  requires  the  key  characters  "TIM  ■" 
followed  by  time  intervals  with  separating  commas.  The  time  intervals  must 
be  in  the  form  ddhhmm-ddhhmm,  where  ddhhmm  indicates  the  day /hour /minute  form 
of  game  time,  and  the  earlier  time  must  be  on  the  left.  The  number  of  time 
Intervals  on  one  card  is  limited  to  six  by  card  size;  however,  multiple  cards 
may  be  used.  The  maximum  number  of  time  intervals  allowable  per  set  is  15. 

If  no  TIM  criteria  card  is  included  in  a  criteria  set,  time  is  not  a  criterion 
for  selection. 


jd.  Class  (CLS)  Criteria  Card.  The  CLS  criteria  card  may 
be  used  to  select  event  records  according  to  class;  i.e. ,  DIVWAG  model  source. 

The  format  of  the  CLS  card  requires  the  key  characters  "CLS  »"  followed  by  a  J 
list  of  class  codes  separated  by  commas.  Desired  classes  should  be  expres- 
sable  on  one  card.  The  following  valid  class  codes  pertain  to  the  model  that 
is  the  source. 


Class  Code 


Model 


1  Area  Fire 

2  Air  Ground  Engagement 

3  Ground  Combat 

4  Intelligence  and  Control 

5  Combat  Service  Support 

6  Movement 

7  Engineer 


D 


e.  Device  (DEV)  Card.  The  user  specifies  the  device 
number  (also  termed  data  set  Identifier  (DSI))  to  which  the  selected  records 
will  be  written  for  the  criteria  set  by  using  the  DEV  card.  Allowable  device 
numbers  are  1,  2,  3,  4,  and  5.  The  format  requires  the  key  characters  "DEV  ■" 
followed  by  the  device  numbers  separated  by  commas,  if  more  than  one. 


required. 


_f.  End  Set  Card.  Only  the  key  characters  "END"  are 


3.  End  of  Selection  Criteria  Card.  This  card  is  Identical 
in  format  to  the  end  of  set  card. 


_4.  Card  Format  Example.  Figure  D-9  shows  a  data  card  set 
example.  In  this  figure,  records  are  selected  from  two  period  history  tapes. 
The  duplicate  input  option  is  not  used.  There  are  four  sets  of  selection 
criteria,  and  four  output  tapes  are  generated.  The  first  set  of  selection 
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criteria  causes  all  records  of  three  Blue  units  and  all  Red  units  to  be 
written  on  DSI  1.  The  second  set  causes  all  records  of  unit  types  EAMT,  EBMI, 
and  those  units  with  UTD  beginning  with  C  and  ending  with  T,  as  well  as  all 
Red  units  to  be  written  on  DSI  2.  The  third  set  causes  all  records  for  Day  1 
to  be  written  on  DSI  3.  The  last  set  causes  all  records  from  the  Area  Fire, 
Air  Ground  Engagement,  and  Ground  Combat  Models  to  be  written  on  DSI  4. 

(c)  Data  Cards  for  Routine  PHIST.  A  single  card  is  input  to 
routine  PHIST.  The  card  contains  three  values,  the  minimum  and  maximum  times 
for  records  to  be  listed  and  the  number  of  period  history  tapes  to  be  input. 
The  times  are  packed  times;  l.e.,  in  the  form  ddhhmm,  where  dd  is  day,  hh  is 
hour,  and  mm  is  minute. 

.1.  Columns  1-21.  The  minimum  time  is  entered,  right 
justified  in  columns  1-6.  The  maximum  time  is  entered,  right  justified  in 
columns  10-15.  Columns  20-21  contain  the  number  of  tapes,  right  justified. 

2.  Columns  7-9,  16-19,  and  22-80.  These  columns  are  Ignored; 
however,  characters  may  be  entered  as  separators  or  comments  in  these  columns. 
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_3.  Card  Format  Example, 
card  for  routine  PHIST. 


Figure  D-10  shows  a  sample  data 


(2)  Deck  Structure.  Figure  D-ll  shows  the  control  cards  and  input 
decks  to  execute  this  job. 

(3)  Job  Request.  Figure  D-12  shows  the  work  request  form  to 
accompany  the  above  deck. 

(4)  Discussion: 

(a)  Control  Cards.  The  job  of  this  example,  HIST,  requires 
120,000  (octal)  words  of  central  memory.  The  central  processing  unit  (CPU) 
time  limit  is  set  to  177  (octal)  seconds.  One  nine-track  tape  drive  is  used. 
The  first  task  the  job  performs  is  to  retrieve,  from  the  disk  library,  the 
executable  routines,  copy  the  three  routines  to  be  executed,  and  return  the 
library  to  the  system.  In  the  second  task,  the  Period  Processor  dump  tape 
is  mounted  on  a  nine-track  tape  drive,  and  the  DIVWAG  data  file  is  loaded  to 
disk  by  routine  UTILLD.  The  tape  drive  and  routine  UTILLD  are  returned  to 
the  system.  The  third  task  is  the  execution  of  routine  UXR  and  the  release 
of  the  routine  and  disk  file  used.  The  fourth  task,  performed  by  routine 
PTAPE,  is  the  creation  of  an  abbreviated  period  history  tape.  It  is  assumed 
that  the  input  has  defined  only  one  qualifier  set  and  Instructed  that  records 
meeting  the  selection  criteria  for  this  set  will  be  written  to  the  disk  file, 
TAPE2.  The  final  task  is  to  list  TAPE2  using  routine  PHIST. 


0 


(b)  Input.  The  deck  in  Figure  D-ll  corresponds  to  a  file 
containing  six  records.  The  first  record  is  the  deck  of  control  cards.  The 
next  three  records  are  C0PYN  instruction  cards;  i.e.,  input  for  the  three 
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executions  of  the  routine  COPYN.  Routines  UTILLD  and  UXR  have  no  card  input 
so  the  fifth  record  is  the  input  deck  for  routine  PTAPE.  The  final  record 
is  the  input  card  for  routine  PHIST. 
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